Banking Modernization: Core Replatform and Digital Front Door

Two flagship programs pulling against each other

The client was a regional bank with 240 branches, roughly 1.4 million retail customers, and a mainframe core that had been in production since 1998. Two board-sponsored programs were already funded when the engagement began. The first was a core replatform onto a modern deposit and lending system, budgeted at 42 million dollars over three years. The second was a digital front-door build, a new mobile and web experience that product had promised to ship in quarterly releases. Each program had its own steering committee, its own vendor, and its own definition of success. Neither had been asked how it depended on the other, and that gap was the real problem the board had funded Stratenity to close.

The friction was already showing in the work. The front-door team wanted to build against the modern core APIs that did not exist yet, so it kept coding against the legacy mainframe adapters it would eventually have to throw away. The core team wanted a code freeze during each migration wave, which would have stalled front-door releases for weeks at a time. The two vendors escalated conflicts to different sponsors, so the same dependency got two answers depending on who asked. The executive team had spent four steering sessions circling the sequencing question without resolving it, and the cost of the delay was becoming visible in a mobile enrollment rate stuck at 34 percent while regional competitors crossed 50. Stratenity was scoped to produce the sequencing decision and the joint operating cadence the decision implied, not another options paper.

One dependency map, one release train, one owner

The first two weeks assembled a shared evidence base. The core migration plan and the front-door roadmap had never been laid on the same timeline, so the team built one that both programs could read together. It exposed 31 hard dependencies between the two programs, of which 9 sat on the critical path. The decisive move was to name the core migration cutover as the master dependency and force the front-door release train to sequence around it, rather than treating the two programs as peers negotiating for the same weeks. Peers negotiate forever. A master dependency gives everyone else a fixed point to plan against.

The plan split the work into waves tied to which customer segments and products moved to the new core, and defined exactly what the front-door team could ship in each window.

Wave 0 was the choice that made the rest possible. Rather than let the front-door team keep building throwaway legacy adapters, the plan funded an API abstraction layer first, so every front-door feature was written once against a stable contract and did not care whether the core underneath was old or new. That single decision converted the migration from a threat to the front-door roadmap into a background event. The board also consolidated both steering committees under a single accountable executive, the Chief Operating Officer, with named decision rights over the freeze calendar. That consolidation was unpopular with two vendor sponsors who lost their direct escalation path, and it was decisive in the result, because a single owner turned a standing argument into a schedule that both teams could plan against with confidence.

What the sequenced program delivered

• Eleven front-door releases shipped across the 18-month core migration, against a prior baseline where front-door work had stalled entirely during migration testing windows.
• Zero cross-program outages. No front-door release triggered a core migration rollback, and no migration wave forced a front-door hotfix, because the freeze windows were agreed months in advance and honored by both teams.
• Mobile enrollment rose from 34 to 58 percent over the program, and digital transaction share crossed 70 percent, reducing branch teller volume enough to defer a planned staffing increase worth roughly 3 million dollars a year.
• The core migration finished six weeks ahead of its 18-month schedule because the abstraction layer removed the ambiguity about which system owned each customer record during cutover.
• Deposit balances held flat to slightly up through every cutover weekend, the metric the board watched most closely, measured against a protected pre-migration baseline.

What the engagement learned

• The sequencing question was never really about order. It was about who owned the freeze calendar. Once one executive owned it, the order resolved itself in a week.
• Funding the API abstraction layer in Wave 0 looked like a detour and was the load-bearing decision. Every dollar spent there removed weeks of throwaway adapter work downstream.
• Naming the cutover as the master dependency let the front-door team plan with certainty instead of renegotiating each release against a moving migration date.
• Two front-door features designed early were retired before launch when the migrated core made them redundant. Building the retirement path into the cadence kept the roadmap honest rather than sentimental.
• The freeze windows shrank wave over wave, from 9 days to 4, as confidence in the cutover mechanics grew. The plan was built to tighten, not just to hold.

How to run this pattern

• Put both program timelines on one page before anything else, and count the hard dependencies. If you cannot name the number, you do not yet have a plan.
• Name a single master dependency and sequence the other program around it. Peers negotiating for the same weeks will never converge.
• Fund an abstraction layer first so downstream work is written once against a stable contract, not repeatedly against a moving one.
• Give one executive named decision rights over the freeze calendar, even when it displaces vendor sponsors.
• Publish freeze windows months ahead and design them to shrink as cutover confidence grows, so certainty rises rather than schedule slips.