BCG Platinion – RetailCore: Legacy Integration

i

Example of an excellent answer (score: 2)

CHART OBSERVATIONS

Integration incidents are the fastest-growing category: ~3.1× growth from month 1 to month 18 — this is not a legacy problem per se, it is an integration layer problem.

Legacy incidents are large but stable: The mainframe itself is not getting worse — it is generating a baseline ~28–31 incidents/month throughout. This signals that simply decommissioning the mainframe will not eliminate all incidents.

Cloud-native incidents are low and flat: The RetailCore platform on its own is well-managed. The issue is entirely at the boundary.

Total incidents are accelerating: The sum is growing month-on-month, driven entirely by integration. Without intervention, the trajectory suggests a crisis within 6–9 months.

STRATEGIC IMPLICATIONS

A great candidate will connect the data to strategy — not just describe the chart:

• The integration layer must be the immediate priority, not the mainframe. A "rip-and-replace" big bang migration solves the mainframe eventually, but does nothing to stop the 3× growth in integration incidents in the short term.
• A Strangler Fig pattern (incremental service migration behind an API abstraction layer) addresses integration incidents directly, while progressively decommissioning the mainframe. This should be the recommended approach.
• The 9-month mainframe expertise cliff creates an urgent timeline constraint: the first phase of the migration must be complete before the IBM z/OS contractors exit.

An excellent candidate should:

• Identify the integration incidents as the fastest-growing and most dangerous category
• Note that legacy incidents are stable (not growing)
• Draw at least one specific strategic implication from the data
• Connect the trend to the budget/timeline tradeoff

Recommended score calculation: starting from 2, decrease by 0.5 for any of the following:

• Candidate only described numbers without drawing implications
• Candidate missed the integration vs. legacy distinction
• Candidate did not connect the trend to strategic urgency

Show Exhibit 2 (the KPI table). Ask the candidate:

"Given what you know about the situation, what are the main architectural approaches available to RetailCore? What criteria would you use to choose between them?"

If the candidate proposes only one approach, challenge: "What alternative would a more risk-averse board prefer, and why?"

If the candidate proposes the Big Bang without mentioning regulatory risk, ask: "How does this approach interact with the ECB/BaFin continuity requirement?"

Example of an excellent answer (score: 2)

STRATEGIC OPTIONS

An excellent candidate identifies at least three distinct approaches:

OPTION A: Big Bang Migration

Full decommission of the mainframe within 12–18 months. High risk (regulatory, operational continuity, data integrity). Fast resolution if successful. Not feasible given the zero-downtime requirement and BaFin oversight of LandBank's banking licence.

OPTION B: Strangler Fig (recommended)
Incremental migration: build an API abstraction layer that intercepts all calls to the mainframe and routes them to new microservices as they are built. Each service is migrated one-by-one, keeping the mainframe running but progressively idle. Addresses the integration incident growth immediately while managing regulatory continuity.

OPTION C: Dual Run Architecture

Operate both systems in parallel indefinitely. Resolves the integration problem by keeping them cleanly separated. Does not decommission the mainframe, so operational cost drag continues. Suitable only as a short-term bridge (0–6 months) before committing to Option B.

SELECTION CRITERIA

A strong candidate uses a structured evaluation framework:

• Regulatory continuity (BaFin/ECB non-negotiable)
• Time to first incident reduction (how quickly does it reduce the growing integration tail?
• Budget fit within €28M
• Knowledge dependency (can it be executed before the IBM contractors exit in month 9?)
• Reversibility (can we course-correct if assumptions prove wrong?)

An excellent candidate should:

• Identify at least 3 distinct strategic options
• Recommend the Strangler Fig or an equivalent incremental approach with clear rationale
• Recognize the regulatory constraint as a hard filter that eliminates Big Bang
• Use a structured evaluation framework (at least 3 criteria)

Recommended score calculation: starting from 2, decrease by 0.5 for any of the following:

• Candidate proposed fewer than 2 options
• Candidate did not flag regulatory risk as a hard constraint
• Candidate could not articulate selection criteria beyond cost
• Candidate recommended Big Bang without acknowledging regulatory risk

Example of an excellent answer (score: 2)

STEP 1 — FRAMEWORK FIRST

An excellent candidate names the workstream taxonomy before any calculation, and explains the logic:

• Workstreams must be MECE: every euro is allocated exactly once. The natural split for a technology migration is: (1) Build — what we create from scratch; (2) Migrate — what we move from old to new; (3) Validate — testing, compliance, sign-off; (4) Protect — knowledge capture before the contractor cliff; (5) Run — programme governance and contingency.
• Sequencing dependency: Build must precede Migrate, which must precede Validate. Protect is time-critical and must run in parallel from day one.

STEP 2 — ANCHOR WITH THE RUN-RATE CROSS-CHECK

Before applying benchmarks, a strong candidate uses the run-rate data as a sanity check:

• Run-rate cross-check: RetailCore's IT run-rate is €42M/year. 18 months = 1.5 years → run-rate over project period = €42M × 1.5 = €63M. The 30% incremental uplift = €63M × 30% = ~€19M. The €28M budget is therefore larger than the pure incremental uplift — meaning it includes some one-off investment costs on top of the run-rate. This is a useful upper-bound check: the allocation must sum to €28M, not to €19M (the incremental cost alone).

STEP 3 — APPLY BENCHMARKS TO DERIVE WORKSTREAM ALLOCATIONS

Using the industry benchmarks provided, derive the allocation ranges and anchor to a specific figure:

STEP 4 — STRATEGIC INSIGHT & CASE LEADERSHIP

Reaching the right total is necessary but not sufficient. An excellent candidate demonstrates case leadership by surfacing the strategic insight embedded in the numbers and connecting it back to the key question of the case:

• Key insight from the allocation: Build (€10M, 36%) dwarfs every other workstream. This means the project's single biggest risk is not budget — it is engineering capacity. At a blended day-rate of ~€800/day for senior engineers, €10M buys roughly 12,500 engineering days over 18 months, equivalent to ~23 full-time engineers. RetailCore currently has 67% of its engineers tied up on legacy maintenance. If that ratio does not improve fast, the build workstream stalls regardless of budget.
• The government subsidy is worth capturing explicitly: 15% of compliance costs (~€3M sub-bucket) = ~€450K recovered. This is not material at programme level but signals to BaFin that RetailCore is engaged in the regulatory process — which accelerates sign-off.
• Recommended next steps from the budget analysis: (1) Immediately ring-fence the €2M Protect workstream and contract IBM z/OS knowledge transfer before month 3; (2) Present the Build workstream headcount plan to the CTO in week one — freeing engineers from legacy maintenance is the critical path; (3) File the Phase 1 BaFin pre-approval application in parallel with the subsidy claim

An excellent candidate should:

• Define the workstream taxonomy (MECE framework) before calculating anything
• Use the run-rate cross-check (€42M × 1.5 × 30% = €19M) as a sanity anchor
• Apply the % benchmarks correctly to €28M to derive ranges, then anchor to a figure
• Calculate the government subsidy impact (15% × compliance sub-bucket)
• Sum to €28M without prompting
• Surface at least one strategic insight from the numbers — not just present the table
• Propose concrete next steps driven by the budget analysis

Recommended score calculation: starting from 2, decrease by 0.5 for any of the following:

• Candidate did not present a framework before calculating
• Candidate could not apply % benchmarks to derive absolute amounts
• Candidate missed or ignored the government subsidy calculation
• Candidate summed to a total other than €28M without acknowledging it
• Candidate produced numbers but drew no strategic insight from the allocation

Example of an excellent answer (score: 2)

WHY STRUCTURE MATTERS IN RISK BRAINSTORMING

An unstructured risk list is not actionable — a board cannot prioritise it, a programme manager cannot assign ownership, and a CEO cannot communicate it. The antidote is to anchor the brainstorm in a MECE taxonomy first. For a technology migration, the natural risk categories follow the three dimensions that determine whether a programme succeeds or fails: can we build it (technical), will the organisation support it (people/change), and are we allowed to do it (regulatory/external). Every risk falls into exactly one of these three buckets.

Category 1: Technical Risks

Can we actually build and run the new architecture at production scale?

• Risk: Data model incompatibility

  The IBM z/OS mainframe uses non-standard data schemas. Migrating them to the new microservices architecture may reveal undocumented data dependencies mid-project, causing delays or data integrity issues.

  Mitigation: Mitigation: ring-fence €4M for dedicated data engineering and run a full data schema audit in month 1 before any migration begins.

• Risk: Integration layer failure under load

  The API abstraction layer must handle 4.2M transactions/day in production. A performance bottleneck in the abstraction layer could make incidents worse, not better, in the short term.

  Mitigation: Mitigation: load-test the API layer at 2× peak capacity before go-live; maintain dual-run fallback to mainframe for 30 days post-launch.

• Risk: Strangler Fig pattern leaving orphan services

  If migration is not completed fully, some mainframe services may remain in a "half-strangled" state — too integrated to revert, too incomplete to decommission. This creates a permanent hybrid architecture.

  Mitigation: Mitigation: establish clear phase gates with binary go/no-go criteria at each service migration milestone.

   

Category 2: People & Organisational Risks

Will the organisation have the capability and alignment to execute?

• Risk: IBM contractor knowledge cliff

  All z/OS expertise sits with 2 contractors whose contracts expire at month 9. If knowledge transfer is not completed before they leave, the migration loses the institutional knowledge needed to complete mainframe decommissioning.

  Mitigation: Mitigation: start knowledge transfer workstream (€2M) in month 1, contract extension clause for contractors through month 12 as a backstop.

• Risk: Engineering capacity bottleneck

  67% of RetailCore engineers are currently tied up in legacy maintenance. If this ratio does not improve quickly, the Build workstream will be under-resourced despite the budget being available.

  Mitigation: Mitigation: CTO must commit to a plan to progressively free engineers from legacy maintenance as each microservice goes live — this is the critical path constraint.

• Risk: Change fatigue and resistance

  The acquisition of LandBank already created significant organisational disruption. A major technology programme on top may generate resistance from LandBank staff who feel their systems are being dismantled.

  Mitigation: Mitigation: establish a joint RetailCore/LandBank migration steering committee; frame communication as "modernising the combined platform", not "replacing LandBank".

   

Category 3: Regulatory & External Risks

Are we allowed to do this, and can we manage external dependencies?

• Risk: BaFin approval delays

  BaFin requires formal sign-off at each migration phase before go-live. If any phase sign-off is delayed by 4–6 weeks, the 18-month timeline collapses and the project runs over budget.

  Mitigation: Mitigation: submit Phase 1 pre-approval application by month 2; assign a dedicated regulatory liaison to maintain weekly BaFin contact.

   

• Risk: ECB/BaFin raises the bar during the project

  Regulatory requirements for digital banking are evolving. BaFin could introduce new requirements mid-project (e.g. expanded audit trail rules) that require scope changes to the compliance workstream.

  Mitigation: Mitigation: build 20% scope contingency into the Validate workstream; monitor EBA and BaFin consultation papers from month 1.

   

• Risk: Vendor concentration risk

  If the API layer or microservices architecture relies heavily on a single cloud vendor (e.g. AWS or Azure), a service outage or pricing change creates a programme-level dependency.

  Mitigation: Mitigation: architect for multi-cloud portability from day one; avoid vendor-specific proprietary services where open alternatives exist.

An excellent candidate should:

• Pause before listing risks and explicitly name the 3 overarching categories
• Use a taxonomy that is MECE — risks should not appear in multiple categories
• Identify at least 2 specific risks per category with concrete mitigations
• Connect at least one risk explicitly to data already seen in the case (e.g. the contractor cliff, the 67% engineer ratio, BaFin sign-off)

What distinguishes excellent from adequate:

• Adequate: lists 6–8 risks with no overarching structure
• Good: uses a structure (e.g. short-term vs. long-term) and names 6+ risks
• Excellent: uses a MECE 3-category taxonomy, provides mitigation for each risk, explicitly references case data, and proactively prioritises the top 2–3 risks by likelihood × impact before concluding

Recommended score calculation: starting from 2, decrease by 0.5 for any of the following:

• Candidate produced a laundry list without any overarching structure
• Candidate generated fewer than 6 distinct risks in total
• Candidate did not provide mitigations for at least half the risks named
• Candidate's categories were not MECE (overlapping or incomplete)

Example of an excellent answer (score: 2)

RECAP OF THE OBJECTIVE

"RetailCore asked us to use the €28M budget to resolve the technology integration problem caused by the LandBank acquisition — specifically, reducing the 60% of incidents attributable to integration friction, within 18 months."

RECOMMENDATION

"We recommend executing a Strangler Fig migration, starting immediately with an API abstraction layer in months 0–9 to directly address the growing integration incident category, followed by incremental microservice migration to progressively decommission the mainframe. This approach fits within €28M, preserves BaFin regulatory continuity, and de-risks the knowledge cliff before IBM contractors exit."

RISKS & NEXT STEPS

"The primary risk is data model incompatibility between the mainframe and the new microservices — we recommend ring-fencing €4M for dedicated data engineering immediately. First next step: mobilise the API layer team in week one and submit Phase 1 to BaFin for pre-approval by month two."

An excellent candidate should:

• Recap the objective in one sentence
• Lead with the recommendation (answer-first), then support it
• Name the primary risk and a mitigation
• Close with two concrete next steps
• Complete the full summary in under 90 seconds

Recommended score calculation: starting from 2, decrease by 0.5 for any of the following:

• Candidate did not lead with the recommendation (buried it at the end)
• Candidate did not cover both the number-of-incidents and budget dimensions
• Candidate did not include risks or next steps
• Candidate spent more than 2 minutes on the conclusion

Thanks for completing the case!

---------------------------

For any questions, please drop me a message here, happy to help.

Best,

Franco