The Integration That Couldn’t Stop the Business Growing

After the acquisition was signed, the hard part began.

Not the announcement. Not the brand story. The reality: two retail wealth platforms, two operating models, two sets of customers; one mandate.

Integrate two platforms while keeping growth on track, and use the moment to improve the customer experience.

I was the program manager. My job was to turn that mandate into decisions, sequencing, and safe execution.

This is the story of how we did it - without naming names - and what I’d do the same way again.

The Real Problem: You’re Integrating While the Plane Is Flying

An integration isn’t a single project. It’s a system of constraints.

• Customers are still onboarding every day.
• Payments still need to settle.
• Order execution needs to continue.
• KYC and regulatory controls can’t blink.
• Mobile apps are the primary channel, so UX issues are amplified.
• And the business wants growth, because “pause revenue” is not an option.

So the first step wasn’t a plan. It was a principle:

We don’t integrate by moving faster. We integrate by removing uncertainty early.

That meant making the core decisions upfront, then letting everything else line up behind them.

Decision 1: Pick the Target Core Banking Engine (and commit)

We had multiple options on the table: provider A, provider B, and an alternative route.

This wasn’t only a vendor decision. It determined:

• product capabilities (now and later)
• data model and migration complexity
• reporting and auditability
• operational processes
• delivery timelines
• integration surface area for every downstream system

We ran it like a proper decision, not a preference contest:

• criteria (capabilities, scalability, cost, fit, risk)
• proof via fit/gap analysis
• and one clear outcome: choose the platform which enables the business to scale.

That decision simplified the migration, reduced uncertainty, and anchored delivery on a platform already proven in production.

Decision 2: Define the Future Architecture (before building anything)

Once the target engine was chosen, the next decision was architecture: how everything connects.

This was the second decision we had to make early, because architecture sets the rules. Once teams start building on assumptions, changing direction becomes expensive fast.

We established the future-state blueprint across the core flows:

• identity and authentication
• payment flows
• KYC/CRM handoffs
• product services
• reporting and data streams

Not as a slide deck, but as a buildable reference: integration patterns, boundaries, and ownership.

Decision 3: Fit/Gap — especially around the core engine

The critical question wasn’t “Can this platform do everything?”

It was: What can it do out of the box, what must we configure, and what must we build around it?

Fit/gap is where integrations either become predictable, or slowly build complexity.

We focused on:

• products and customer types
• account and portfolio structures
• onboarding and KYC process differences
• payments and settlement mechanics
• regulatory reporting requirements

This gave us a realistic backlog and eliminated magical thinking.

The Move That Kept Growth Alive: Redirect New Onboarding

Here’s the integration move that mattered most.

We didn’t wait for the final migration to “become one.” We changed the flow of new business early.

We introduced a new onboarding approach that routed new product onboarding into the target platform, so no new clients/accounts were created in the legacy core.

That gave us:

• A clear cut-over line in time.
• Zero new legacy: no new clients/accounts in the old core.
• Proven end-to-end journeys (UI/UX, onboarding, and servicing) for the products we were migrating.
• Fewer edge cases and cleaner migrations.
• Faster convergence to a single operating model.

It sounds simple, but it requires discipline and cross-team alignment. This is where many programs hesitate. We didn’t.

Modernize Along the Way: Payments and Native Apps

Integration is the rare moment when you can change things that are normally “too hard to touch.”

We used that window.

• We brought in a new payment provider to support the target flow and reduce operational friction.
• We built new native apps for the acquired client base to support the experience on the target platform.

Both choices improved customer outcomes and reduced long-term complexity. But they also added delivery scope—which is why sequencing mattered so much.

Migration as a Machine: Mapping, Rehearsals, and Two Cutovers

Once the target state was stable and onboarding was redirected, we could treat migration like what it should be:

a repeatable process, not a single event.

We executed it in deliberate stages:

1. Data mapping between the two cores
   (ownership, portfolio structures, transaction history, documents, identifiers)

2. Test migrations to validate mappings and tooling
   (find surprises early)

3. Dress rehearsals like a production deployment
   (timed runs, checklists, data cleansing, rollback plans, operational readiness)

4. Friends & family
   a controlled pilot with tight feedback loops

5. Migration wave 1
   execute with confidence the first batch of clients

6. Migration wave 2
   execute with confidence the complex products and clients

Two waves weren’t bureaucracy. They were risk management.

The Friends & family teaches you what your spreadsheets and development environments will never tell you:

• where people actually get stuck
• which edge cases really exist
• what ops needs at 02:00
• what the customer experiences, not what the requirements said

What Actually Made It Work

Looking back, the success wasn’t one hero moment. It was the compounding effect of a few program fundamentals:

• Make irreversible decisions early (core engine, architecture)
• Stop the legacy footprint from growing (redirect onboarding)
• Treat migration like a product release (rehearsals, pilots, waves)
• Modernize where it reduces future complexity (payments, apps)
• Operate as one team (business + tech + ops + risk)

The Outcome

The integration wasn’t just a consolidation exercise.

It was a shift from “two platforms with a migration plan” to “one platform with a controlled migration pipeline.”

The business kept moving. The platform became simpler. And customers experienced change as progress, not disruption.

That is what good integration looks like: not flashy, but engineered.