Merging Salesforce orgs after an acquisition is rarely the 90-day project leadership expects. Two codebases carry years of undocumented customization, two data models rarely agree on what a "customer" even is, and your DevOps pipeline has to serve both orgs until the day you actually cut over. Get the sequencing wrong and you spend eighteen months firefighting instead of six months consolidating.
Most IT Directors inherit this problem mid-deal. Legal signs the paperwork, the press release goes out, and then someone asks why the acquired company's Service Cloud cases aren't showing up anywhere. The business already assumes the systems are "basically connected." They are not, and pretending otherwise is how merger projects blow their first quarter.
What Breaks First When You're Merging Salesforce Orgs
The first casualty is usually automation. Both orgs have validation rules, flows, and triggers built by different admins with different conventions. Combine the record volume and you often trip governor limits that neither org hit on its own. A flow that fired fine on 400 records a day chokes when it suddenly processes 4,000.
The second casualty is naming collisions. Two orgs independently built a field called Region__c that mean different things, or two Process Builders fire on the same object with conflicting logic. None of this shows up in a demo. It shows up three weeks after go-live when a rep closes a deal and the commission calculation silently fails.
The third, and the one leadership underestimates most, is API capacity. Running integrations, migration jobs, and the acquired company's legacy middleware against one org at once is a fast way to burn through your daily API allocation before lunch. Plan for this early or you will be explaining an outage during the exact week executives are watching the numbers closest.
Mask the Data Before Anyone Touches the Metadata
Before a single developer opens a sandbox to start reconciling the two orgs, the acquired company's production data needs masking. That org likely holds customer PII, pricing terms you are not yet contractually allowed to see in detail, and possibly data subject to a different regulatory regime than your own, especially if the acquisition brings in EU or healthcare customers.
This is where most integration teams cut corners, because masking feels like a delay when the deal clock is already running. It is not optional. A full-copy sandbox of an acquired org, handed to a consulting team or offshore developers unmasked, is exactly the kind of exposure that turns an M&A win into a breach disclosure. We built MaskEzee for this specific moment: mask the acquired org's sandbox data before anyone outside the core data room touches it, and keep referential integrity intact so the records still make sense for testing.
The teams that skip masking usually have a reason that sounds sensible in the moment. "We only need this for two weeks." Two weeks is plenty of time for a laptop to go missing or a consultant's access to outlive the project. Mask first, build second.
Picking a Consolidation Path Before You Write Any Code
There are really only a few honest options once the data is safe to work with. You can merge everything into one org, run the acquired org as a semi-independent instance connected by integration, or operate both in parallel for a defined transition period before deciding. Each one has a different DevOps footprint, and picking the wrong one costs you months.
A full merge gives the cleanest long-term state but demands the most upfront engineering: object mapping, deduplication, permission set redesign, and a hard cutover weekend that has to work the first time. Hub-and-spoke keeps the acquired org alive longer, which buys time but means maintaining two deployment pipelines, two release calendars, and two sets of governor limits indefinitely. Parallel run is the slowest and most expensive option, but it is sometimes the only realistic choice when the acquired company's processes are too different to map cleanly on day one.
My honest take: companies default to hub-and-spoke because it feels lower-risk, then discover a year later they are paying for two of everything with no consolidation date on the calendar. If leadership commits to a timeline, commit to a full merge path and hold the line on it.
Deployment Sequencing Across Two Codebases
Once you have a path, the deployment order matters as much as the destination. Metadata dependencies that were invisible in each org's own pipeline become very visible the moment you try to deploy combined changes. A flow referencing a custom object that does not exist yet in the target org will fail the whole deployment, not just that component.
This is where version control discipline pays off immediately. If either org has been managing metadata through change sets instead of a proper repository, stop and fix that first. You cannot safely sequence a merger deployment without a clear, diffable record of what each org actually contains right now, not what someone remembers building two years ago.
DeployEzee was built around exactly this kind of dependency-aware deployment: it maps what depends on what before anything moves, so a merger deployment does not die halfway through because a permission set referenced a profile that got renamed six months ago in the other org. For a merger project, that validation step is not a nice-to-have. It is the difference between a clean weekend cutover and a Monday morning full of broken flows.
Testing With Data That Looks Like the Combined Business
Here is a problem nobody mentions in the merger planning deck: your test data from before the acquisition does not represent the business you are building. Sandbox records that reflect only your original product catalog and pricing will not catch the edge cases that show up once the acquired company's SKUs, discount structures, and approval chains get layered in.
Masked production data solves the privacy problem but not this one, because masked data from each org separately still tests each org separately. What UAT actually needs is data shaped like the post-merger business: records that combine both product lines, both approval hierarchies, both support tiers, so testers can catch the scenarios that only exist once the two companies are actually one.
SproutEzee exists for this gap. It builds production-like data in a sandbox without waiting on a full-copy refresh, which matters a lot during a merger timeline where you cannot afford to lose a week every time you need fresh combined test data. Seed a sandbox with records that reflect the merged reality, not the pre-deal one, and UAT sign-off actually means something.
Realistic Timelines for 500 to 5,000 Employee Orgs
For a company in this size range, a genuine Salesforce org merger, metadata reconciliation, data migration, integration cutover, user retraining, usually runs nine to fifteen months if done properly. Anything advertised faster than six months for a company this size is either a very simple acquisition or a plan that is skipping steps it will pay for later.
The phases that actually take time are rarely the ones in the project plan's headline milestones. Object and field mapping between two orgs with years of customization takes longer than anyone estimates. Permission and sharing model reconciliation takes longer still, because two companies almost never structured roles and territories the same way, and getting that wrong creates visibility problems that look like security incidents.
Build the timeline around the slow parts, not the fast ones. Data masking and seeding can run in parallel with mapping work if you set them up early, which is often the single biggest schedule recovery available to a merger project that is already behind.
Frequently Asked Questions
How long does it typically take to merge two Salesforce orgs after an acquisition?
For a company between 500 and 5,000 employees, a full org merger usually takes nine to fifteen months when done properly, including metadata reconciliation, data migration, and user retraining. Projects promising a faster timeline are usually either very simple acquisitions or plans that skip steps like permission model reconciliation and proper UAT, which surface as problems after go-live instead.
Should we mask the acquired company's Salesforce data before our developers access it?
Yes, and this should happen before anyone outside the core deal team touches a sandbox copy of the acquired org. That data likely contains customer PII and commercial terms that are not yet appropriate to expose broadly, and unmasked full-copy sandboxes handed to consultants or offshore teams create real compliance exposure. Tools like MaskEzee can mask that data while keeping referential integrity intact for testing.
What is the difference between a full merge and a hub-and-spoke consolidation model?
A full merge combines both companies into a single Salesforce org with one data model, one set of automation, and one deployment pipeline, which takes more upfront engineering but gives the cleanest long-term state. Hub-and-spoke keeps the acquired org running semi-independently and connects it through integration, which is faster to stand up but means maintaining two pipelines and two release calendars indefinitely unless a firm consolidation date is set.
Why do deployments fail when combining metadata from two separate Salesforce orgs?
Deployments fail most often because of dependency conflicts that were invisible when each org managed its own metadata separately, such as a flow referencing an object or field that does not exist yet in the target org. Naming collisions between objects, fields, or automation built independently by two admin teams also cause failures that rarely show up until the deployment actually runs.
How do we create realistic test data for a merged Salesforce org during UAT?
Masked production data from each original org tests each business separately, which misses the edge cases created once both companies' products, pricing, and approval chains combine. Seeding a sandbox with data that reflects the merged business, including both product lines and organizational structures, gives UAT testers a realistic picture. SproutEzee builds this kind of production-like data in a sandbox without requiring a full-copy refresh cycle.