<\/p>\n
MIGRATION \/ APPLICATION MODERNIZATION<\/span><\/p>\n 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 \u2014 turning migration into a capability the organization owns, with AI, platform engineering and FinOps each doing a specific job.<\/p>\n By BAP IT JSC\u3000|\u3000Published 4 September 2026<\/p>\n<\/div>\n 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.<\/p>\n 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.<\/p>\n 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<\/strong>. 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.<\/p>\n Worth being explicit: this is not a product name. Buying migration automation tooling does not give you a Migration Factory. Four things carry it.<\/p>\n PEOPLE<\/span><\/p>\n Migration architects, the platform team, business owners, QA and operations engage as a standing function rather than a project roster.<\/p>\n Role: hold the quality of decisions and keep experience inside the organization.<\/p>\n<\/div>\n PROCESS<\/span><\/p>\n The path from discovery to decommissioning is defined, and every wave runs the same sequence through the same gates.<\/p>\n Role: reduce variance and make progress comparable across waves.<\/p>\n<\/div>\n PLATFORM<\/span><\/p>\n Landing zone, CI\/CD, observability and security baselines exist before the first wave, so no team rebuilds them.<\/p>\n Role: cut time to first deployment and make governance a default rather than a review.<\/p>\n<\/div>\n DATA<\/span><\/p>\n Inventory, dependencies, progress, quality and cost live in one source of truth that everyone reads.<\/p>\n Role: base decisions on evidence rather than on the loudest status report.<\/p>\n<\/div>\n<\/div>\n Five pressures tend to push organizations from project thinking to portfolio thinking at roughly the same time.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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<\/strong>. The standardization investment only pays back across volume \u2014 which is also the honest counter-argument: if you have a handful of workloads to move, run them as projects and skip the factory.<\/p>\n<\/div>\n 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.<\/p>\n 01<\/span><\/p>\n APPLICATION PORTFOLIO INTELLIGENCE<\/span><\/p>\n Establishing, as fact, what exists and how it connects. No credible discussion about migration patterns can happen before this is done.<\/p>\n Why it matters: <\/strong>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.<\/p>\n<\/div>\n 02<\/span><\/p>\n MIGRATION PATTERNS AND GOLDEN PATHS<\/span><\/p>\n 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.<\/p>\n Why it matters: <\/strong>The point is not to narrow the options. It is to stop paying for the same architectural debate on every wave<\/strong>. Exceptions will happen; the discipline is keeping them visible rather than informal.<\/p>\n<\/div>\n 03<\/span><\/p>\n WAVE PLANNING ENGINE<\/span><\/p>\n 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.<\/p>\n Why it matters: <\/strong>Wave design is a business decision as much as a technical one. If continuity of operations<\/strong> is a requirement, business owners have to be in the planning, or the rework surfaces later at a far higher cost.<\/p>\n<\/div>\n 04<\/span><\/p>\n AUTOMATED QUALITY GATES<\/span><\/p>\n Progress to the next stage is decided by what has been demonstrated, not by who signed off. The gate criteria stay constant across waves.<\/p>\n Why it matters: <\/strong>Where business behaviour is not meant to change, evidence of functional equivalence is the deliverable<\/strong>. Automating the gates is what keeps verification quality constant as the number of waves grows.<\/p>\n<\/div>\n 05<\/span><\/p>\n FINOPS AND UNIT ECONOMICS<\/span><\/p>\n 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 \u2014 not a tooling choice.<\/p>\n Why it matters: <\/strong>Deferring the cost conversation produces the familiar outcome: the migration completed and the run rate overshot. Cost visibility at design time<\/strong> is what makes a pattern choice defensible to a CFO.<\/p>\n<\/div>\n 06<\/span><\/p>\n KNOWLEDGE FLYWHEEL<\/span><\/p>\n 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.<\/p>\n Why it matters: <\/strong>Without this, the other five can all be in place and wave two is still no faster than wave one<\/strong>. What should remain at the end is not only a running system but an organization that can operate and extend it.<\/p>\n<\/div>\n Of the six, AI moves the needle most on 01 and 04<\/strong>. Classifying source, extracting dependencies, reconstructing lost documentation, generating test cases \u2014 all work that used to consume months of specialist effort, now compressible by a large factor.<\/p>\n What AI cannot close on its own is equally clear. Legacy code carries more than logic; it carries exceptions and the history behind them<\/strong>. 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 \u2014 static analysis returns these as code, not as intent. Only someone who understands the business can classify them.<\/p>\n The working model is AI-assisted and expert-led, with humans in the loop<\/strong>. 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.<\/p>\n<\/div>\n A factory separates standing roles<\/strong> from roles assembled per wave<\/strong>. Writing down who decides what is not bureaucracy here \u2014 it is what keeps the quality gate from becoming the place where decisions stall.<\/p>\n Reference role split for a Migration Factory. Smaller organizations will combine several of these.<\/p>\n 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.<\/p>\n 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.<\/strong><\/p>\n<\/div>\n 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.<\/p>\n Priorities vary by organization. What follows is delivery guidance, not a fixed template for any country \u2014 treat it as a starting point to confirm with the specific client.<\/p>\n<\/div>\n 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.<\/p>\n FLOW METRICS<\/span><\/p>\n QUALITY METRICS<\/span><\/p>\n BUSINESS METRICS<\/span><\/p>\n KNOWLEDGE METRICS<\/span><\/p>\n One caution on metric design: optimize flow alone and the quality gate becomes ceremonial.<\/strong> Flow and quality have to be read as a pair. Everything above is a measurement item \u2014 targets should come out of your own discovery, not from an industry average.<\/p>\n<\/div>\n 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.<\/p>\n<\/div>\n<\/details>\n 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.<\/p>\n<\/div>\n<\/details>\nKey takeaways<\/h2>\n
\n
What a Migration Factory actually is<\/h2>\n
People<\/h4>\n
Process<\/h4>\n
Platform<\/h4>\n
Data<\/h4>\n
Why the model matters now<\/h2>\n
The estate is interconnected<\/h3>\n
Deadlines converge<\/h3>\n
Variance becomes run cost<\/h3>\n
Compliance is easier to build in than to retrofit<\/h3>\n
Knowledge evaporates<\/h3>\n
The six building blocks<\/h2>\n
Application portfolio intelligence<\/h3>\n
\n
Migration patterns and golden paths<\/h3>\n
\n
Wave planning<\/h3>\n
\n
Automated quality gates<\/h3>\n
\n
FinOps and unit economics<\/h3>\n
\n
The knowledge flywheel<\/h3>\n
\n
Where AI belongs<\/h3>\n
Team design and ownership<\/h2>\n
\n\n
\n \nRole<\/th>\n Primary accountability<\/th>\n Continuity<\/th>\n<\/tr>\n<\/thead>\n \n Portfolio owner<\/th>\n Sets priority across the estate, approves wave sequence, reports to the executive sponsor<\/td>\n Standing<\/td>\n<\/tr>\n \n Migration architect<\/th>\n Defines patterns, rules on pattern fit, adjudicates exceptions<\/td>\n Standing<\/td>\n<\/tr>\n \n Platform team<\/th>\n Landing zone, CI\/CD, observability, shared services \u2014 build and improve<\/td>\n Standing<\/td>\n<\/tr>\n \n Wave team<\/th>\n Design, build, test and cut over the assigned wave<\/td>\n Per wave<\/td>\n<\/tr>\n \n Application owner<\/th>\n Confirms business behaviour, explains exception rules, signs off acceptance<\/td>\n Per domain<\/td>\n<\/tr>\n \n QA and security<\/th>\n Sets and verifies gate criteria, owns security and compliance evidence<\/td>\n Standing<\/td>\n<\/tr>\n \n FinOps<\/th>\n Cost visibility, cost input into pattern comparison, post-migration optimization<\/td>\n Standing<\/td>\n<\/tr>\n \n Operations and SRE<\/th>\n Monitoring design, first-line response at cutover, confirms stable running<\/td>\n Standing<\/td>\n<\/tr>\n \n Delivery lead and bridge engineer<\/th>\n Progress and issue management, cross-language and cross-timezone alignment<\/td>\n Standing<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n A reference process<\/h2>\n
Operating across regions and time zones<\/h2>\n
Global and distributed teams: asynchronous autonomy<\/summary>\n
\n
Japan: consensus and evidence<\/summary>\n
\n
South Korea: speed with visibility<\/summary>\n
\n
Vietnam: staged investment and knowledge transfer<\/summary>\n
\n
Metrics that matter<\/h2>\n
Flow<\/h4>\n
\n
Quality<\/h4>\n
\n
Business<\/h4>\n
\n
Knowledge<\/h4>\n
\n
Common failure modes<\/h2>\n
1. Buying tooling before defining the operating model<\/summary>\n
2. Optimizing only for cutover speed<\/summary>\n
3. Automating an unstable process<\/summary>\n