MC Connector and Business Units- Should a test BU that is going to be connected to SF CRM SIT be the child BU of the BU that is MCC with SF CRM Prod?

Question

We are about to create an SFMC test BU for a Business unit with our SFMC Account. I am wondering if it is best practice to make this test BU a child of the BU that is the production one. Basically we have an Account parent BU and below that is a child BU. This child BU uses the MCC to synch with our SF CRM prod org. Should we have the test BU that will use MCC to synch the SF CRM SIT org the child of the one the synchs with the SF CRM prod org?

a) Is a child of
Account Parent
      >Brand A Prod_BU
         >Brand A Test BU

b) Is Not a child of 
 Account Parent
      >Brand A Prod_BU
      >Brand A Test BU

Answer 1

I have a suspicion this might be closed as opinion-based.

...is it even "best practice" to use multiple BUs for sandboxing? Who is to say. In order to keep opinions out and stick to reproducible things, let's say "there are considerations you should make". The potential BU hierarchy is not really among them:

• There is no real data isolation inside SFMC. With sandbox and prod connected, you in effect mix prod and test data to some degree (e.g. all subscribers list), among other risks this has effects on your billable contact count;

• deployment from test to prod has "manual steps" (when graciously taking into account that things like the API, package manager etc exist and you have put a lot of effort into covering most things automatically), which makes deployment an additional error source in itself rather than a "mechanical" step to enforces synchronicity. In other words: If you change something in sandbox, chances are you have to retest it all over again in prod. Sidenote: this starts with the connector package itself which is not deployable but is two separate installs.

• add to that: The existence of an Enterprise Level BU stays in place in the backend as a remnant of the BU hierarchy. This means that code in Sandbox and Live cannot be equal - e.g. a script or an SQL query in any other but the former parent BU still has to use "ENT." prefix to access, say, All Subscribers, or other Enterprise level entities, like the _open dataview. The same script will break once moved to prod = Parent BU ,until you remove "ENT." - in such scenarios, deployment could be the only error source in a script that worked flawlessly in Sandbox.

• Any Contact ID is a Contact ID, no matter what system it comes from. Plus, Sandbox Refreshes will recreate all Ids, including User, Lead, Contact which will create billable duplicates that you should take care of.

• Sandbox refreshes can lead to other problems such as: https://help.salesforce.com/s/articleView?id=000322378&type=1

• marketing cloud releases are rolled out by Salesforce regardless of what you call your BU >> "sandbox" and "prod" BUs receive global changes at the same time.

• Do not use your sandbox for load testing or similar as detrimental effects can also impact prod.

• your sandbox is not "harmless" as it is not really a sandbox. You can e.g. totally send data to the wrong people at scale, in seconds. Every additional measure you put in to prevent this has to be built in such a way that it only occurs in the sandbox and exists, but is ignored in prod.

If this sounds like a best practice to you, or if you have other arguments that outweigh this, is probably the more opinion-based part :)