0

I have the duty to migrate a production org into a new(fresh new) Salesforce org, only metadata wise. That includes custom objects, customization to standard objects, proccess builders, approval process, any custom code and any other particular configuration in the org. I realise I have two tools for doing this: ANT and Salesforce DX with VisualStudio code.
I was wondering what are you people approach to this kind of task? Any good strategies? Better tools?

I am facing right now a huge amount of dependencies errors trying to deploy all the metadata(tried both ANT and SFDX). I am trying to resolve them one by one but they are a lot. Looks like an order problem when deploying but reading about this it shouldn´t be a problem with Salesforce confusing and not deploying the items with no dependencies first, am I right?
I discover that some of the errors are for configurations that are not "expresed" in the metadata, for example Person Accounts should be enabled in the new org, or custom domain should be used. I start wondering if all this dependencies issues are related to configurations in the old org like that one.

Any help/advice will be well recieved.
Thanks in advance.

  • Have you checked this – sanket kumar Feb 17 at 14:42
  • @sanketkumar thanks for that. No idea about that DOT cloning solution. I will need to check that with Salesforce tech support. – Matías Quintana Feb 17 at 15:03
3

Merging two Salesforce production orgs can be a massive and complex task. The concern that I'm feeling upon reading your post is that it sounds like your business team has not evaluated the customizations in the two Salesforce orgs and determined what the final org should look like. That's a serious shortcoming, especially when org-level feature changes like Person Accounts are involved!

The first step, for me, is documentation. What is the scope of customizations in the two orgs? Do they both include Apex code, declarative customization, schema, reports, page layouts? What does that customization do, and are the business processes implemented compatible with one another? Further, what are the orgs' feature sets - is one a different edition than another, the Person Accounts question, the sharing models, and so forth.

The second phase would be to take that documentation to your business teams and map out the desired combination of functionality and org structure. With significant divergence between the configurations and business processes modeled in the two orgs, this can be a complex and lengthy discussion.

Only once you have that thorough documentation and business process analysis in place can you, as a developer, begin a line-level analysis of the metadata you are migrating from Org B into Org A, to ensure that it is compatible with the target configuration and make remediations along the way. Scratch orgs may actually help here, since you can easily spin them up with various configurations representing how you hope the final org will look. Depending on the outcome of your business analysis, you might have changes to make in Org A and its metadata as well.

Often, you'll find that initial deployments of metadata into a new org surface hundreds or thousands of errors. However, those errors also often have a small number of underlying causes: either metadata fails for the same or similar reasons (say a Record Type is missing, causing all of the Profiles to fail), or one component fails upon which many others have a dependency, causing them too to fail. Finding those key touch points can dramatically reduce the scope of the errors you need to consider and triage.

Needless to say, everything should be thoroughly tested in a full-copy sandbox before being deployed to the surviving production org.

| improve this answer | |
  • That's a nice clear view of the situation. I must clarify that the new org is a fresh new org, that in fact it hasn´t been purchased yet. I'm testing and creating a migration strategy in a regular dev org and having access to, of course, the "old" prod org. Problem is that there isn't any propper doc about this project. So my resources are this old org and some tech partner in my client side to show me and explain me how the business works. I had the hope to migrate this without too much knowledge of the actual buisness, just like move this from A to B but I think it will not be that simple... – Matías Quintana Feb 17 at 17:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.