The documentation page for "Restore a Sharded Cluster" makes a number of implicit assumptions.

These assumptions should be explicitly mentioned in the documentation, in order to avoid confusion.

Firstly, the documentation assumes that you are either restoring onto the same hostnames, or if not, then you are restoring onto new hostnames where the old environment is no longer accessible from the destination environment. If the old environment is accessible, when you spin up the config servers and mongos, they will attempt to reach out to the old shard servers.

You will then see messages like this:

mongos> show collections
Mon Dec  8 23:36:44.806 error: {
	"$err" : "could not initialize sharding on connection foo/bar0:27201,bar1:27201,bar2:27201,bar3:27201,fsap7:27201 :: caused by :: mongos specified a different config database string : stored : mongo-configs-1:27280,mongo-configs-2:27280,mongo-configs-3:27280 vs given : staging-foo-configs-1:17280,staging-foo-configs-2:17280,staging-foo-configs-3:17280",
	"code" : 15907
} at src/mongo/shell/query.js:128

Secondly, the documentation assumes that you are restoring either onto the same source cluster, or onto a new cluster that has been configured identically - not onto a new blank cluster, or one with different hostnames.

If you do try to do it onto a blank cluster, particularly one with different hostnames, you will hit some issues.

Ideally, it would be nice if the most efficient way of doing this particular type of restore was also documented as well.