Case Study · Salesforce migration

Customer: Travelcard

“A bi-directional sync, a careful migration, and one very satisfying moment when the second org went dark for good.”

Merging two Salesforce orgs is one of those projects that sounds straightforward on paper — and then humbles you the moment you start mapping objects. You're dealing with duplicate records, conflicting field names, divergent processes, and users who have been working in their respective environments for years. Get it wrong and you don't just break a system; you erode trust.

This is the story of how we did it in two deliberate stages, kept both orgs alive and in sync during the transition, and ultimately sunset one of them cleanly — with users barely noticing the shift.

Project overview

Two orgs, multiple teams, one target state. The goal was full operational consolidation without disrupting live business processes or losing any historical data along the way.

Stage one: building the bridge

Before we could migrate anything, we needed both orgs to coexist peacefully. That meant building a bi-directional data synchronisation solution that could handle updates flowing in either direction simultaneously — without creating loops, conflicts, or data loss.

The architecture centered on custom metadata types. Rather than hardcoding any object or field relationships, we defined all mappings declaratively: which objects to sync, which fields to include, how to resolve naming differences, and critically — how to handle conflicts when both sides changed the same record.

The priority system was one of the most important design decisions we made. When two users in different orgs updated the same account within the same sync window, the system needed a deterministic rule to decide which value survived. We configured this at the field level — some fields deferred to the primary org, others to the secondary, and a small set used a timestamp-wins approach. All of this was configurable through metadata, with no code changes required to adjust a rule.

Field mapping also had to account for structural differences. Some objects existed in one org but not the other. Some fields held the same data under different API names. The metadata layer handled all of this gracefully, translating between schemas without any manual transformation logic embedded in triggers or flows.

We ran stage one for a sustained period, stress-testing the sync under real production load, monitoring for drift and anomalies, and progressively expanding the set of synced objects. Only once the bridge was stable and trusted did we move to stage two.

With the sync layer proven, stage two focused on the remaining challenge: historical data. Active records were already flowing between orgs, but years of closed opportunities, archived contacts, legacy cases, and supporting data lived exclusively in the secondary org — untouched by the sync because they weren't changing.

We designed the migration to bring that data into the primary org while respecting the data segregation model both organisations required. Users from each side needed visibility into their own records and controlled access to shared data — not a single undifferentiated pool. We implemented ownership rules, sharing settings, and record type distinctions to preserve those boundaries within a single org.

The process alignment work ran in parallel. Different teams had evolved different workflows, approval processes, and naming conventions. Rather than forcing one team's way of working onto the other, we facilitated joint process reviews and built shared flows that respected how each group actually worked — with sensible defaults agreed between them.

Once the data was in place and the processes were aligned, all users moved to the primary org. From their perspective, it was simply a new login URL and a familiar-but-improved interface. The data they needed was there. The workflows they depended on were there. The transition generated less disruption than most routine system updates.

The moment the second org went on dark mode

Decommissioning the secondary org was the project's final milestone — and the one that made everything feel real. After months of running two environments in careful coordination, we turned one off. No fanfare, no incident. The sync listener went quiet, the secondary org's users were fully onboarded elsewhere, and the environment was archived.

A few things stand out in retrospect. Building the sync layer first meant we never had a hard cutover with a big-bang data migration and a frozen production window. The move was incremental and reversible at every step. Custom metadata made the sync configuration transparent and adjustable without engineering involvement for every tweak. And the explicit priority model prevented the ambiguity that kills data integrity in bidirectional sync scenarios.

The data segregation requirement — often seen as a complication — actually helped. It forced us to be precise about ownership and access from the start, which made the merged org's governance model stronger than either of the originals.

If you're scoping a similar project, the key investment is in the bridge: get the sync right, run it long enough to trust it, and the migration becomes a logistics exercise rather than a technical gamble.