Implementation Roadmap & Migration

The Phased Implementation Approach

Implementing a Target Operating Model is not a single event — it is a multi-year programme of interconnected changes spanning people, processes, technology, governance, and data. The scale and complexity of TOM implementation in banking demands a phased approach that manages risk, builds capability progressively, and delivers value incrementally.

Crawl-Walk-Run

The crawl-walk-run framework is the most widely used phasing model for TOM implementation in banking:

Crawl Phase (Months 1-6 typically)

The crawl phase establishes foundations and delivers early, lower-risk changes that build confidence and momentum:

• Programme governance: Establish the programme steering committee, workstream structure, reporting cadence, and decision-making framework
• Quick wins: Implement changes that deliver immediate value with low risk — process standardisation, documentation improvements, KPI dashboards, and small-scale automation
• Foundation building: Deploy enabling infrastructure — programme management tools, collaboration platforms, knowledge repositories, and communication channels
• Detailed planning: Develop detailed plans for the walk and run phases, including resource requirements, timelines, dependencies, and risk assessments
• Pilot migrations: Execute small-scale technology migrations or process changes to test approaches and build migration capability
• Change management: Launch communication campaigns, stakeholder engagement, and training programmes to prepare the organisation for larger changes ahead

The crawl phase is about proving the approach — demonstrating that the programme can deliver tangible results, that the governance works, and that the organisation can absorb change. The credibility built during this phase is essential for securing continued investment and stakeholder support for the more disruptive changes ahead.

Walk Phase (Months 7-18 typically)

The walk phase tackles the structural changes that reshape the operating model:

• Major technology migrations: Migrating core processing platforms, with parallel running and phased cutover
• Organisational restructuring: Implementing the new organisational design — establishing shared services centres, transitioning staff to new roles, executing reductions where required
• Process redesign: Deploying redesigned processes across the organisation, with training, parallel running, and controlled rollout
• Data migration: Migrating data from decommissioned systems to target platforms, with rigorous validation and reconciliation
• Governance implementation: Activating new governance structures, committee cadences, and decision-rights frameworks
• Location transitions: Opening new centres, transferring work to new locations, and closing legacy offices

The walk phase is the most resource-intensive and highest-risk period. Change is happening across multiple dimensions simultaneously, and the organisation is operating in a hybrid state — partly in the old model, partly in the new. This requires intensive programme management, clear communication, and robust issue and risk management.

Run Phase (Months 19-30 typically)

The run phase completes the transition and embeds the target operating model:

• Final migrations: Completing any remaining technology migrations and decommissioning legacy systems
• Performance optimisation: Tuning the target model based on operational experience — adjusting processes, refining automation, optimising resource allocation
• Benefits realisation: Validating that projected benefits are being achieved and addressing any shortfalls
• Continuous improvement: Embedding continuous improvement practices — regular process reviews, performance benchmarking, and innovation initiatives
• Programme closure: Formally closing the programme, transitioning residual activities to business-as-usual, and conducting a comprehensive lessons-learned review

Phasing by Dimension vs Phasing by Function

TOM implementation can be phased in two ways:

By dimension: All process changes first, then all technology changes, then all organisational changes. This approach ensures deep focus on each dimension but creates a long timeline and delays integration benefits.

By function: Each operational function (e.g., settlement, reconciliation, payments) is transformed end-to-end — process, technology, organisation, and governance — before moving to the next function. This approach delivers integrated benefits faster but requires broader capability in the programme team.

Most banking TOM programmes use a hybrid approach — some foundational changes are phased by dimension (e.g., governance framework first, then technology infrastructure), while the main transformation is phased by function (e.g., settlement end-to-end, then reconciliation end-to-end).

Migration Planning

Technology and process migration is the highest-risk activity in TOM implementation. Getting it wrong can disrupt client service, create operational losses, and attract regulatory scrutiny. Rigorous migration planning is therefore essential.

Parallel Running

Parallel running is the gold standard for risk management during platform migration. Both the old and new platforms process the same transactions simultaneously for a defined period. The outputs — settlement instructions, reconciliation results, regulatory reports, client statements — are compared systematically. Any discrepancies are investigated, root-caused, and resolved.

Parallel running provides confidence that the new platform produces correct results before the old platform is decommissioned. The duration of parallel running depends on the complexity and risk of the migration:

• Low-risk migrations (e.g., reporting tools, internal dashboards): 2-4 weeks of parallel running
• Medium-risk migrations (e.g., reconciliation platforms, client reporting): 4-8 weeks
• High-risk migrations (e.g., settlement platforms, payment processing, regulatory reporting): 8-16 weeks, covering at least one full month-end cycle, one quarter-end, and ideally one year-end

Parallel running is resource-intensive — it requires additional processing effort, comparison and investigation effort, and the continued operation of the old platform. This cost must be planned and budgeted. However, the cost of parallel running is negligible compared to the cost of a failed migration.

Cutover Strategies

The cutover is the point at which the old platform is decommissioned and the new platform becomes the sole production system. There are several cutover strategies:

Big bang cutover: All processing switches to the new platform at a single point in time (typically a weekend or holiday). This is the simplest approach but carries the highest risk — if the new platform fails, there is no easy fallback. Big bang cutovers are used for low-to-medium complexity migrations where the risk is manageable and parallel running has provided high confidence.

Phased cutover: Processing is migrated in phases — by product, by client, by market, or by entity. For example, settlement for European equities might be migrated first, followed by fixed income, then derivatives. This approach reduces risk because each phase is smaller and more manageable, and lessons from early phases inform later ones. However, it creates a period where the old and new platforms must coexist, requiring careful management of data synchronisation and process handoffs.

Pilot cutover: A small subset of processing (a single client, a single product, or a single market) is migrated first as a live pilot. The pilot operates in production for a defined period, and only if it performs successfully is the broader migration executed. This approach provides the strongest risk mitigation but extends the overall timeline.

Data Migration

Data migration — moving data from legacy systems to target platforms — is consistently one of the most underestimated activities in banking transformation. Challenges include:

• Data quality: Legacy systems often contain poor-quality data — missing fields, inconsistent formats, duplicate records, and outdated information. This must be cleansed before migration.
• Data mapping: The data model in the target system rarely matches the source system exactly. Detailed mapping rules must be defined for every data element — how it maps from source to target, what transformations are required, and how exceptions are handled.
• Volume: Large banks may need to migrate billions of transaction records, millions of position records, and hundreds of thousands of reference data records. This requires careful planning of migration windows, performance testing, and contingency for migration failures.
• Validation: Every migrated record must be validated — does the data in the target system match the source? Automated comparison tools are essential for large-volume migrations.
• Historical data: Decisions must be made about how much historical data to migrate. Regulatory requirements may mandate retention of historical transaction data for 5-7 years, which may need to be migrated to the new platform or retained in an accessible archive.

Dependency Mapping

A TOM implementation involves hundreds of interconnected activities. Dependency mapping identifies the relationships between these activities, revealing:

• Hard dependencies: Activity B cannot start until Activity A is complete. For example, data migration cannot begin until the target platform is installed and configured.
• Soft dependencies: Activity B is easier or lower risk if Activity A is complete first, but it is not strictly required. For example, staff training is easier after processes are documented, but training can begin with draft documentation.
• External dependencies: Activities that depend on external parties — vendors, regulators, market infrastructure providers, or clients. These are often the least controllable and most impactful dependencies.

The dependency map is typically represented as a network diagram or Gantt chart showing the critical path — the longest sequence of dependent activities that determines the minimum programme duration. Activities on the critical path must be managed with particular attention, because any delay on the critical path delays the entire programme.

Managing Dependencies in Banking

Banking introduces unique dependencies that are less common in other industries:

• Market calendar dependencies: Migrations cannot be planned during high-volume trading periods, year-end processing, regulatory reporting deadlines, or corporate actions seasons. The available migration windows may be limited to specific weekends or holiday periods.
• Regulatory dependencies: Material changes may require regulatory notification or approval, which has its own timeline that must be factored into the plan.
• Market infrastructure dependencies: Changes affecting connectivity to CSDs, CCPs, payment systems, or SWIFT require coordination with those institutions, which operate on their own schedules.
• Client dependencies: Changes affecting client reporting, connectivity, or service must be communicated and coordinated with clients, who may have their own migration requirements.

Resource Planning

TOM implementation requires significant resources — both dedicated programme resources and business-as-usual staff who must contribute to the transformation while maintaining daily operations.

Programme Team

A typical banking TOM programme team includes:

• Programme Director: Senior leader accountable for the overall programme, typically reporting to the COO or a board-level sponsor
• Workstream Leads: One for each major dimension or function — technology migration, process redesign, organisational change, governance, data
• Business Analysts: Document requirements, design processes, map data, and define test cases
• Technology Architects: Design the target technology landscape, define integration architecture, and oversee platform selection
• Change Managers: Lead stakeholder engagement, communication, training, and cultural change
• Project Managers: Manage individual projects within the programme, tracking scope, schedule, budget, and risk
• Subject Matter Experts (SMEs): Operational staff seconded to the programme to provide domain expertise — they know how things actually work
• Testing Team: Design and execute test strategies, manage defects, and validate readiness for go-live

Business Contribution

In addition to the dedicated programme team, business-as-usual operations teams must contribute significant effort to the transformation — participating in design workshops, testing new systems, training on new processes, and supporting parallel running. This effort is often underestimated, leading to business teams being stretched between daily operations and transformation commitments. The TOM implementation plan must explicitly account for this business contribution and ensure that operational capacity is protected.

Risk Management During Transition

The transition period — when the organisation is partly in the old model and partly in the new — is the highest-risk phase. Specific risks include:

Operational disruption. Errors, delays, and service failures during migration, cutover, or process change. Mitigation: parallel running, phased cutover, rollback plans, and enhanced monitoring during transition.

Data loss or corruption. Data quality issues during migration, synchronisation failures between old and new systems during parallel running, or incomplete migration. Mitigation: comprehensive data validation, reconciliation between source and target, and the ability to re-run migrations.

Staff attrition. Key staff leaving during the transition — either because they are displaced by the new model and leave early, or because uncertainty about the future drives voluntary attrition. Mitigation: retention arrangements for critical staff, clear communication about future roles, and knowledge transfer programmes.

Scope creep. The programme taking on additional scope beyond the original TOM design, diluting resources and extending timelines. Mitigation: rigorous change control, a clear scope boundary documented in the programme charter, and governance discipline to assess and approve any scope changes.

Regulatory intervention. The regulator raising concerns about the transformation — particularly if it involves significant offshoring, technology changes, or organisational restructuring. Mitigation: proactive regulatory engagement, demonstrating robust risk management, and maintaining the ability to pause or modify the programme if supervisory concerns arise.

Quick Wins vs Long-Term Structural Changes

A well-designed implementation roadmap balances quick wins (changes that deliver immediate, visible value) with long-term structural changes (fundamental improvements that take longer but deliver greater value).

Quick Wins

Quick wins build momentum, demonstrate programme value, and maintain stakeholder support during the long structural transformation:

• Process documentation: Documenting previously undocumented processes — immediate value for audit, training, and regulatory compliance
• KPI dashboards: Deploying operational dashboards that provide real-time visibility of performance — immediate value for management decision-making
• Small-scale automation: Automating specific manual tasks using RPA — immediate productivity improvement
• Policy and governance clean-up: Rationalising outdated policies, clarifying decision rights, and simplifying committee structures
• Training programmes: Upskilling staff on target state processes and systems, building capability ahead of migration

Long-Term Structural Changes

These are the transformative changes that define the target operating model:

• Platform migration: Moving from legacy to target technology platforms
• Organisational restructuring: Implementing shared services, location strategy, and new team structures
• Process redesign: Fundamentally redesigning end-to-end processes for automation and efficiency
• Data architecture transformation: Implementing golden source strategy, data governance, and data lineage
• Governance overhaul: Implementing new governance frameworks, decision rights, and control structures

The key is sequencing: quick wins in the crawl phase build credibility and momentum; structural changes in the walk and run phases deliver the transformative value.

Regulatory Engagement During Transformation

Banking TOM transformations invariably involve changes that are of interest to regulators. Proactive, transparent engagement with supervisors is essential for managing regulatory risk.

What Regulators Want to Know

• Scope and rationale: What is changing and why? Regulators want to understand the strategic rationale and expected benefits.
• Risk management: How is the bank managing the risks of transformation? What are the key risks and mitigations?
• Client impact: Will clients be affected? How is client communication managed?
• Operational continuity: How will the bank ensure that critical business services are maintained throughout the transition?
• Outsourcing and offshoring: If the transformation involves material outsourcing or offshoring, regulators will scrutinise the arrangements against their outsourcing requirements.
• Governance: Who is accountable for the programme? What is the governance structure?
• Fallback plans: If something goes wrong, what is the bank's contingency plan?

Engagement Approach

• Early notification: Inform the regulator of the planned transformation before it begins — not after.
• Regular updates: Provide periodic updates on programme progress, including any issues or delays.
• Material change notifications: Formally notify the regulator of material changes (e.g., outsourcing, offshoring) as required by applicable regulations.
• Documentation: Maintain comprehensive documentation of the transformation — business case, risk assessments, migration plans, and test results — available for supervisory review.

Banking Example: 18-Month Settlement Platform Migration

Consider a European investment bank — let us call it Meridian Capital — migrating its settlement platform from a 15-year-old on-premise legacy system to a modern cloud-based platform. The legacy system processes 45,000 settlement instructions per day across equities, fixed income, and exchange-traded derivatives, settling through 12 European CSDs plus Euroclear and Clearstream.

Programme Structure

Phase 1: Foundation (Months 1-4)

• Platform selection and contract negotiation completed (Months 1-2)
• Environment set-up — cloud infrastructure provisioned, connectivity established, integration framework designed (Months 2-3)
• Configuration — settlement rules, CSD connectivity, matching logic, and exception workflows configured in the new platform (Months 3-4)
• Test strategy designed, test data prepared, and test environments provisioned (Month 4)
• Regulatory notification submitted to the home regulator, outlining the scope, rationale, and risk management approach (Month 2)
• Staff training programme launched — online courses, workshop sessions, and hands-on system training (Month 4 onwards)

Phase 2: Testing and Parallel Running (Months 5-12)

• System integration testing (SIT): End-to-end testing of all settlement workflows, CSD connectivity, exception handling, and reporting (Months 5-7)
• User acceptance testing (UAT): Operations teams execute real-world scenarios on the new platform, validating functional correctness, usability, and performance (Months 7-9)
• Performance testing: Stress testing with peak-day volumes (2x normal), testing system capacity and response times under load (Month 9)
• Parallel running (Phase A — European equities only): Both platforms process live equities settlement for 8 weeks. Outputs are compared daily. A dedicated comparison team investigates all discrepancies. The acceptance criteria: fewer than 5 unexplained discrepancies per 10,000 instructions for 10 consecutive business days (Months 9-11)
• Parallel running (Phase B — all asset classes): Parallel running is extended to fixed income and ETDs. The same acceptance criteria apply (Months 11-12)
• Regulatory checkpoint: Present parallel running results to the regulator, demonstrating readiness for cutover (Month 12)

Phase 3: Phased Cutover (Months 13-16)

• Cutover 1 — European equities (Month 13): Over a weekend, the new platform becomes the primary settlement system for equities. The legacy system remains available in standby mode for 4 weeks as a fallback. Enhanced monitoring is deployed for the first 2 weeks.
• Cutover 2 — Fixed income (Month 14): After 4 weeks of stable equities operation, fixed income is migrated using the same weekend cutover approach.
• Cutover 3 — Exchange-traded derivatives (Month 15): After 4 weeks of stable fixed income operation, ETDs are migrated.
• Legacy system standby deactivation (Month 16): After 4 weeks of stable operation across all asset classes, the legacy system is decommissioned. Data is archived according to the retention policy (7 years for transaction data).

Phase 4: Stabilisation and Optimisation (Months 17-18)

• Post-go-live support: Enhanced support model with extended hours, additional staff, and rapid escalation paths for the first 4 weeks after final cutover
• Performance monitoring: Intensive KPI monitoring — STP rates, fail rates, cycle times, CSD rejection rates — compared against pre-migration baseline and target state objectives
• Defect resolution: Any remaining defects or issues identified during early live operation are resolved through a prioritised defect backlog
• Process optimisation: Fine-tuning settlement rules, matching algorithms, and exception workflows based on live operational experience
• Benefits validation: Initial validation of projected benefits — reduced processing time, improved STP rates, lower fail rates — against the business case
• Programme closure: Formal programme closure, lessons-learned review, handover to business-as-usual operations and BAU technology support

Data Migration

Historical settlement data migration is planned as a separate workstream:

• Active positions and pending instructions: Migrated to the new platform before parallel running begins
• Historical transaction data (7 years): Migrated to a searchable archive, accessible for audit, regulatory inquiry, and dispute resolution
• Validation: Complete reconciliation of migrated data against source — position balances, instruction counts, and historical P&L attribution

Risk Register

Key risks identified and managed throughout the programme:

1. CSD connectivity failure: Risk that one or more CSD connections do not function correctly on the new platform. Mitigation: dedicated CSD connectivity testing stream, direct engagement with each CSD's technical team.
2. Data migration errors: Risk that migrated data contains errors affecting live processing. Mitigation: two rounds of migration rehearsal before live migration, comprehensive validation.
3. Staff resistance: Risk that operations staff resist the new platform due to unfamiliarity. Mitigation: comprehensive training programme, super-users embedded in each team, feedback channels.
4. Volume spike during parallel running: Risk that a market event causes a volume spike during parallel running, overwhelming both platforms. Mitigation: performance testing to 3x normal volumes, ability to suspend parallel running if necessary.
5. Regulatory objection: Risk that the regulator raises concerns that delay the cutover. Mitigation: proactive engagement from Month 2, regular updates, formal checkpoint at Month 12.

In the next module, we will explore how to measure the success of a TOM implementation — defining KPIs, tracking benefits, building operational dashboards, and embedding continuous improvement.