MIGRATION / APPLICATION MODERNIZATION
Every migration project ends the same way: the hard-won knowledge stays with the people who did the work, and the next project starts from zero. A Migration Factory is the operating model that breaks that cycle — turning migration into a capability the organization owns, with AI, platform engineering and FinOps each doing a specific job.
By BAP IT JSC | Published 4 September 2026
Key takeaways
- A Migration Factory is an operating model, not a tool or a product you can buy.
- AI compresses discovery and automation, but it does not replace expert judgement.
- Platform engineering supplies golden paths so every team stops reinventing the same decisions.
- FinOps makes cost an input to architecture, not a report you read afterwards.
- Each migration wave must leave behind something that makes the next wave faster.
What a Migration Factory actually is
Most organizations treat their first migration as a project. A team is assembled, an approach is chosen, the workload moves, the system stabilizes, and the team disbands. Nothing about that is wrong. The problem is that the first migration is almost never the last one.
When there are dozens or hundreds of applications to move, repeating the project model produces predictable results: approaches diverge, quality bars shift with whoever is running the wave, and lessons from the last effort never reach the next one. Teams find themselves running the same discovery, at the same cost, on the third migration as on the first.
A Migration Factory changes that structure. Instead of a sequence of one-off projects, migration is designed as a standing capability with standardized patterns, a shared platform, a repeatable process and a body of knowledge that compounds. The factory metaphor is not about uniform mass production. It is about accepting that the same process will run many times, and therefore investing in the process itself.
Worth being explicit: this is not a product name. Buying migration automation tooling does not give you a Migration Factory. Four things carry it.
People
PEOPLE
Migration architects, the platform team, business owners, QA and operations engage as a standing function rather than a project roster.
Role: hold the quality of decisions and keep experience inside the organization.
Process
PROCESS
The path from discovery to decommissioning is defined, and every wave runs the same sequence through the same gates.
Role: reduce variance and make progress comparable across waves.
Platform
PLATFORM
Landing zone, CI/CD, observability and security baselines exist before the first wave, so no team rebuilds them.
Role: cut time to first deployment and make governance a default rather than a review.
Data
DATA
Inventory, dependencies, progress, quality and cost live in one source of truth that everyone reads.
Role: base decisions on evidence rather than on the loudest status report.
Why the model matters now
Five pressures tend to push organizations from project thinking to portfolio thinking at roughly the same time.
The estate is interconnected
Workloads leaving a mainframe or a data centre are rarely independent. They call each other, share reference data and compete for the same batch window. Deciding application by application produces an estate that is individually optimized and collectively incoherent.
Deadlines converge
Hardware and middleware end-of-support, data centre lease expiry, and a change in cloud policy do not queue politely behind one another. They arrive together, and sequential delivery stops being viable.
Variance becomes run cost
When every wave lands in a slightly different shape, operations inherits a different runbook and a different monitoring configuration each time. The moment migration finishes, post-migration diversity starts billing you.
Compliance is easier to build in than to retrofit
Identity, encryption, logging, residency and separation of duties are cheap when they are baked into the landing zone and expensive when they are added application by application after the fact. A factory makes security and compliance a property of the path, not a task on each project plan.
Knowledge evaporates
This is the least visible loss. Why a pattern was chosen, what broke, and how it was handled disperse when the project closes. The next team rediscovers the same traps at full price.
The goal of a Migration Factory is not raw speed on the first wave. It is making every wave after the first one faster, cheaper and more predictable. The standardization investment only pays back across volume — which is also the honest counter-argument: if you have a handful of workloads to move, run them as projects and skip the factory.
The six building blocks
Six capabilities have to be present for the model to hold. Remove any one and the others keep working, but the whole thing quietly reverts to a set of individual projects.
01
Application portfolio intelligence
APPLICATION PORTFOLIO INTELLIGENCE
Establishing, as fact, what exists and how it connects. No credible discussion about migration patterns can happen before this is done.
- Inventory of applications, jobs, batch chains, reports, interfaces and data stores
- Dependency mapping of call chains and data flows
- Separating live assets from dead ones using actual runtime evidence
- Classification by business criticality, change frequency and technical complexity
- Reconstructing specifications where documentation no longer exists
Why it matters: The size of the programme is set here. Excluding assets that nobody actually uses is usually the single largest reduction in scope you will find, and every downstream estimate depends on it.
02
Migration patterns and golden paths
MIGRATION PATTERNS AND GOLDEN PATHS
A pre-agreed answer to “an application shaped like this moves this way, onto this target configuration.” A golden path is the route a team can take without needing to relitigate the architecture.
- Selection criteria for rehost, replatform, refactor and rebuild
- Reference architectures and templates per application archetype
- Standard data migration approach, including encoding and data type handling
- An explicit exception route — deviations are approved and recorded, not forbidden
Why it matters: The point is not to narrow the options. It is to stop paying for the same architectural debate on every wave. Exceptions will happen; the discipline is keeping them visible rather than informal.
03
Wave planning
WAVE PLANNING ENGINE
Rather than moving everything at once, the estate is cut into groups by dependency and risk, and sequenced. This is where incremental migration stops being a slogan and becomes a schedule.
- Grouping by dependency to find genuinely separable units
- Reconciliation with the business calendar — period close, peak trading, regulatory reporting
- Cutover approach per wave, and whether parallel running is required
- Rollback criteria and named decision-makers agreed in advance
- Design for old-to-new data flow during the transition window
Why it matters: Wave design is a business decision as much as a technical one. If continuity of operations is a requirement, business owners have to be in the planning, or the rework surfaces later at a far higher cost.
04
Automated quality gates
AUTOMATED QUALITY GATES
Progress to the next stage is decided by what has been demonstrated, not by who signed off. The gate criteria stay constant across waves.
- Unit, component and integration testing
- Output comparison between legacy and target for batch processing
- Data reconciliation
- Performance testing, particularly batch completion inside the operational window
- Security validation and configuration compliance checks
- Regression testing and user acceptance testing
- Rehearsal in a production-equivalent environment, including a rollback drill
Why it matters: Where business behaviour is not meant to change, evidence of functional equivalence is the deliverable. Automating the gates is what keeps verification quality constant as the number of waves grows.
05
FinOps and unit economics
FINOPS AND UNIT ECONOMICS
Cost is treated as an input to design decisions rather than a report produced after go-live. As the FinOps Foundation frames it, this is an operating practice across engineering, finance and the business — not a tooling choice.
- Cost visibility per application and per wave
- Tagging and account structure built into the landing zone standard
- Projected run cost included in the comparison of migration patterns
- Continuous optimization against observed post-migration usage
- Reading cost per unit — per transaction, per customer, per order — rather than in totals
Why it matters: Deferring the cost conversation produces the familiar outcome: the migration completed and the run rate overshot. Cost visibility at design time is what makes a pattern choice defensible to a CFO.
06
The knowledge flywheel
KNOWLEDGE FLYWHEEL
The element that makes it a factory rather than a queue. Every completed wave has to leave assets behind that make the next one shorter.
- Playbook updated after each wave, including how exceptions were handled
- Reusable conversion scripts, test data and comparison tooling
- A record of decisions: which pattern was chosen, and what was ruled out
- Knowledge transfer to the client-side team and support for in-house capability
- Consistent terminology, naming and documentation format
Why it matters: Without this, the other five can all be in place and wave two is still no faster than wave one. What should remain at the end is not only a running system but an organization that can operate and extend it.
Where AI belongs
Of the six, AI moves the needle most on 01 and 04. Classifying source, extracting dependencies, reconstructing lost documentation, generating test cases — all work that used to consume months of specialist effort, now compressible by a large factor.
What AI cannot close on its own is equally clear. Legacy code carries more than logic; it carries exceptions and the history behind them. A branch that exists for one counterparty, a rounding rule that encodes an accounting policy, a date check written around a regulation that has since been amended — static analysis returns these as code, not as intent. Only someone who understands the business can classify them.
The working model is AI-assisted and expert-led, with humans in the loop. AI supplies speed in analysis and generation; legacy specialists, architects, QA and business owners hold verification. Programmes that blur that boundary find out at the quality gate, which is the most expensive place to find out.
Team design and ownership
A factory separates standing roles from roles assembled per wave. Writing down who decides what is not bureaucracy here — it is what keeps the quality gate from becoming the place where decisions stall.
Reference role split for a Migration Factory. Smaller organizations will combine several of these.
| Role | Primary accountability | Continuity |
|---|---|---|
| Portfolio owner | Sets priority across the estate, approves wave sequence, reports to the executive sponsor | Standing |
| Migration architect | Defines patterns, rules on pattern fit, adjudicates exceptions | Standing |
| Platform team | Landing zone, CI/CD, observability, shared services — build and improve | Standing |
| Wave team | Design, build, test and cut over the assigned wave | Per wave |
| Application owner | Confirms business behaviour, explains exception rules, signs off acceptance | Per domain |
| QA and security | Sets and verifies gate criteria, owns security and compliance evidence | Standing |
| FinOps | Cost visibility, cost input into pattern comparison, post-migration optimization | Standing |
| Operations and SRE | Monitoring design, first-line response at cutover, confirms stable running | Standing |
| Delivery lead and bridge engineer | Progress and issue management, cross-language and cross-timezone alignment | Standing |
A reference process
The sequence every wave runs. Holding the order constant is what makes progress comparable across waves and knowledge cumulative. The amber steps are gates: the wave does not advance until they pass.
The last step is the one most often dropped, and it is the one that separates a factory from a queue. A playbook nobody updates stops being used by the second wave.
Operating across regions and time zones
Where delivery spans offshore, nearshore and client-side teams, the operating assumptions differ by region and are worth making explicit rather than discovering mid-programme.
Priorities vary by organization. What follows is delivery guidance, not a fixed template for any country — treat it as a starting point to confirm with the specific client.
Global and distributed teams: asynchronous autonomy
- Communication: assume time zones do not overlap; put everything a decision needs into writing.
- Reporting: continuous visibility through dashboards; reserve live meetings for exceptions and decisions.
- Decision-making: define delegated authority up front and let teams move inside it without seeking confirmation.
- Quality gates: weight automated conformance; keep human review for exceptions.
- What resonates: business outcomes, scalability, security and compliance by design, measurable delivery.
Japan: consensus and evidence
- Communication: share the reasoning and the alternatives considered, not only the conclusion.
- Reporting: document-based reporting on a regular cadence; raise issues when they appear rather than after they are solved.
- Decision-making: consensus takes longer, and decisions change less afterwards. Plan for that shape rather than against it.
- Quality gates: design evidence at a fine granularity — a test result records the comparison basis and conditions, not just a pass.
- What resonates: stable operation, continuity of business processes, rehearsal and rollback readiness, Japanese-language delivery.
South Korea: speed with visibility
- Communication: lead with the conclusion and the next action.
- Reporting: short reporting cycles with progress dashboards.
- Decision-making: a compressed PoC often settles the approach, followed by rapid scale-out.
- Quality gates: automation and DevSecOps built in, so control does not cost speed.
- What resonates: operational stability, cost optimization, automation, scalability.
Vietnam: staged investment and knowledge transfer
- Communication: technical vocabulary in English, business requirements confirmed in the local language.
- Reporting: cost and progress preferred in a single view.
- Decision-making: incremental investment that keeps existing assets in play; full replacement is rarely the starting assumption.
- Quality gates: automation combined with explicit knowledge transfer to the in-house team.
- What resonates: a roadmap that fits the budget, reuse of what already works, flexible team scaling.
Metrics that matter
Whether the factory is working is a measurement question, not an impression. The categories below are what to measure. Baselines differ enough between estates that the only sensible starting point is your own first wave.
Flow
FLOW METRICS
- Cycle time per wave
- Lead time from discovery to pattern decision
- Number of waves running concurrently
- Variance against the plan
Quality
QUALITY METRICS
- First-pass rate at the quality gate
- Post-cutover incidents by severity
- Rollbacks triggered, and why
- Discrepancies found in batch comparison, by category
Business
BUSINESS METRICS
- Share of the estate migrated
- Realized savings from decommissioned environments
- Run cost per application
- Change in release cycle time
Knowledge
KNOWLEDGE METRICS
- Golden path adoption rate and exception count
- Reuse of scripts, tests and tooling
- Playbook update frequency
- Steps the client-side team can now run unaided
One caution on metric design: optimize flow alone and the quality gate becomes ceremonial. Flow and quality have to be read as a pair. Everything above is a measurement item — targets should come out of your own discovery, not from an industry average.
Common failure modes
1. Buying tooling before defining the operating model
Migration automation pays off once the process it automates exists. Introduced before the process and the patterns are settled, the tool ends up shaping the workflow, and exception handling multiplies. Decide who decides what first.
2. Optimizing only for cutover speed
Compressing the cutover window while stabilization and decommissioning slip is a common pattern. Until the legacy environment is switched off, you are paying for both. A migration is finished at decommissioning, not at go-live.
3. Automating an unstable process
Automating a procedure that is still changing means editing the automation on every exception, and maintenance load grows faster than the saving. A workable rule: run the same procedure manually three times before you automate it.
4. Bringing FinOps in at the end
Aggregate cost after the fact and neither the tagging nor the account structure supports the breakdown you need — you cannot say what any single application costs. Cost visibility belongs in the landing zone standard from the start.
5. Letting every team keep its own data
The architect holds the inventory, delivery holds the progress, finance holds the cost, and none of the numbers reconcile. Meetings turn into reconciliation exercises and decisions slow down. Agreeing the single source of truth precedes selecting any tool.
6. Closing the programme at go-live
Set go-live as the finish line and optimization, decommissioning and the playbook update never happen. The next wave then costs what the last one did. A migration that leaves no learning behind never becomes a capability, however many times you run it.
Where BAP fits
BAP works on legacy system modernization, COBOL-to-Java code migration, cloud migration and database migration. Within a Migration Factory, the engagement typically covers:
- Discovery and portfolio visibility — inventory, dependency mapping, and reconstructing specifications through business interviews.
- Proof of concept — validating the conversion approach, target architecture and test method before committing at scale, and tightening the estimate.
- Incremental migration — wave design and execution by business and data domain.
- Build and test — Java/Spring development, web UI and reporting rebuild, data migration, and end-to-end quality assurance from unit test through UAT.
- Delivery models — offshore, onsite and hybrid, with support in English, Japanese, Korean and Vietnamese.
- Post-migration operations and handover — stabilization support and knowledge transfer to the client-side team.
A substantial share of BAP’s delivery history is with Japanese enterprise clients, where documentation discipline, demonstrable functional equivalence and stable operation are treated as non-negotiable. Those are the same three constraints that decide whether a core-system migration is trusted anywhere else.
One caveat worth stating plainly: outsourcing an entire Migration Factory defeats its purpose. A repeatable capability has to end up on the client side to be worth building. The useful engagement shape is to establish the pattern on the first waves, build out the standards and playbook, and hand over something the organization can run.
Closing
A Migration Factory is not a new category of tooling. It is an operational choice: accept that migration will run many times, and build the process, platform, data and team for that reality before the volume arrives.
The decision itself is not complicated. With a handful of workloads, run them as projects — it will be faster and cheaper. With dozens or more, converging deadlines and the same judgement calls recurring, the standardization investment has a realistic path to payback.
Either way, the first move is the same. Inventory the estate and map the dependencies. Until the size and shape are visible, the choice between models is speculation.
References
Build a repeatable modernization capability
Tell us the size of the estate, what it depends on, and which support deadlines you are working against. We will set out where to start, which steps are worth standardizing first, and what a realistic first wave looks like. Early-stage conversations are welcome.
Explore BAP’s System Migration Services
A description of your current environment is enough to start.
