Enterprise AI Migration Planning: Where AI ROI Either Compounds or Evaporates
This article applies the TOGAF 10 Architecture Development Method (ADM), particularly its migration-planning discipline, to enterprise AI transformation. The AI-specific frameworks, models, and terminology presented here are the author's applied methodology, not formal TOGAF terminology.
Why AI Transformation Must Be Sequenced as a Capability Migration
Enterprise AI rarely fails because an organization cannot identify AI use cases.
The harder problem begins after the opportunities have been identified.
An enterprise may have dozens of credible AI initiatives across customer service, sales, operations, finance, engineering, knowledge management, and decision support. Each may have an attractive business case. Yet the organization can still spend heavily on AI without building a durable enterprise capability.
The problem is often migration sequencing.
The order in which AI capabilities are introduced determines what the enterprise can reuse, what it must rebuild, what dependencies emerge, what risks accumulate, and how efficiently subsequent initiatives can be delivered.
This is where Enterprise Architecture becomes critical.
AI ROI compounds when each migration wave creates reusable capabilities that increase the value, feasibility, and efficiency of subsequent waves.
Conversely, ROI can erode when AI initiatives are optimized independently and disconnected from the architecture required for the next stage of transformation.
From AI Use Cases to Enterprise Capability
A conventional AI portfolio asks:
Which use case should we implement first?
A migration-oriented architecture asks:
Which sequence of initiatives moves the enterprise from its Baseline Architecture toward the Target Architecture while delivering measurable business value along the way?
That is a fundamentally different question.
Consider two organizations.
One implements five successful AI applications, each with its own model access, retrieval, evaluation, monitoring, security, and integration patterns.
The other implements five applications while progressively establishing reusable capabilities such as:
- governed model access
- enterprise knowledge and retrieval
- common evaluation
- observability
- security and authorization patterns
- reusable integration services
- agent orchestration
- AI governance and operational controls
Both may have five production AI applications.
But only the second is systematically increasing the enterprise's reusable AI capability.
The objective is therefore not simply more AI applications.
It is more enterprise capability generated per unit of AI investment.
The Two Dimensions of AI Value
Traditional business cases naturally emphasize direct value:
- revenue
- cost reduction
- productivity
- quality
- customer outcomes
- cycle-time reduction
- risk reduction
These remain essential.
But enterprise migration can create a second form of value: capability enablement.
An initiative may establish reusable:
- architecture patterns
- data and knowledge capabilities
- retrieval services
- evaluation mechanisms
- security controls
- governance mechanisms
- integration patterns
- observability
- operating practices
- organizational skills
Therefore, an AI initiative should be evaluated at three levels:
What value does it create now?
What reusable capability does it create?
What future initiatives does that capability enable?
A foundational initiative with modest direct value may still have strategic importance when it removes a dependency for multiple future initiatives.
That does not mean every platform investment should be funded. It means its value must be considered within the migration sequence, not only within the economics of its first consuming application.
Why the Easiest Use Case Is Not Always the Right First Step
Starting with an easy, low-risk use case can provide valuable:
- business evidence
- stakeholder confidence
- operational learning
- delivery experience
- initial value
The problem occurs when ease becomes the dominant sequencing criterion.
A relatively simple use case may create almost no reusable capability.
A more demanding initiative may establish a capability required by several subsequent initiatives.
Therefore:
The easiest AI use case is not necessarily the most valuable first migration step.
The architect should instead consider:
- business value
- strategic alignment
- capability enablement
- dependencies
- data readiness
- architecture readiness
- risk
- complexity
- time to value
- organizational readiness
- reusability
- lifecycle economics
The goal is not to maximize the ROI of one project.
It is to optimize the sequence of transformation.
The AI Capability Dependency Graph
AI initiatives should be viewed as a dependency graph rather than an independent project list.
For each initiative, the architecture should identify:
Business Capability
What business capability is being transformed?
Data Capability
What data must be available, trusted, governed, and accessible?
Knowledge Capability
What enterprise knowledge must be represented, retrieved, and maintained?
Intelligence Capability
Does the solution require generation, prediction, classification, reasoning, recommendation, planning, or decision support?
Retrieval Capability
Does it require keyword, semantic, hybrid, graph-based, or structured-data retrieval?
Execution Capability
Does it require tools, workflows, agents, planning, or controlled action execution?
Trust Capability
How are identity, authorization, privacy, security, policy, and auditability handled?
Quality Capability
How is AI quality evaluated continuously?
Operational Capability
How are availability, latency, failures, model behavior, and cost managed?
The result is a migration dependency graph showing:
What must exist before an initiative can proceed, what the initiative creates, and which future initiatives can reuse it.
This is considerably more useful than a use-case backlog alone.
Applying TOGAF Phase F to Enterprise AI Migration
The TOGAF ADM provides a useful discipline for this problem.
Phase F is Migration Planning.
Phase F develops the detailed Implementation and Migration Plan and finalizes the Architecture Roadmap, based on the selected migration approach and the outcomes of the preceding ADM phases.
For AI transformation, this means asking:
How do we move from the Baseline Architecture toward the Target Architecture through a viable sequence of changes that delivers business value and manages risk?
This is where AI migration becomes more than project scheduling.
It becomes an architectural transition from the current enterprise state to the desired future state.
The relationship with Transition Architectures is important. Transition Architectures are identified as part of the Opportunities & Solutions work in Phase E and then incorporated into the migration planning and roadmap developed through Phase F.
Baseline → Transition → Target
An enterprise should rarely assume that it can move directly from its current AI state to its ultimate target.
For example:
Baseline Architecture
- isolated AI experiments
- fragmented model access
- local knowledge stores
- inconsistent evaluation
- limited observability
- manually applied governance
↓
Transition Architecture 1
- governed model access
- common security patterns
- initial evaluation
- centralized observability
↓
Transition Architecture 2
- enterprise knowledge services
- reusable retrieval
- standardized AI integration
- shared platform capabilities
↓
Transition Architecture 3
- governed agent execution
- policy-controlled tools
- workflow integration
- continuous evaluation
↓
Target Architecture
- reusable enterprise AI capabilities
- integrated knowledge
- governed intelligent execution
- continuous evaluation and operations
- institutionalized AI operating model
These transition states make the target architecture achievable without requiring the enterprise to make every architectural commitment at once.
The Principle of Just-Enough Foundation
There is an important balance.
Building every conceivable AI platform capability before validating business demand creates speculative investment.
Building every AI initiative independently creates fragmentation.
The practical principle is:
Build enough reusable foundation to enable the next economically justified migration wave, but not enough to solve every hypothetical future problem.
For example, if several near-term initiatives require common model access, identity propagation, retrieval, evaluation, and observability, those capabilities may justify shared investment.
But building a sophisticated multi-agent platform for unvalidated future use cases may not.
Migration planning therefore requires progressive architectural commitment.
Commit where dependencies are clear.
Preserve optionality where uncertainty remains high.
AI Sequencing Debt
Organizations can accumulate what I call AI Sequencing Debt.
This occurs when individual AI initiatives are technically successful but collectively create an inefficient transformation path.
Typical symptoms include:
- duplicated AI infrastructure
- multiple model gateways
- fragmented knowledge stores
- incompatible evaluation approaches
- duplicated retrieval pipelines
- disconnected observability
- inconsistent security controls
- point-to-point integrations
- excessive vendor coupling
- fragmented operating practices
Each solution may be defensible in isolation.
The problem appears at the portfolio level.
Local architectural optimization can create global transformation inefficiency.
Sequencing debt is therefore different from conventional technical debt. It arises from the architecture and ordering of the transformation itself.
An Applied AI Migration-Wave Model
A migration wave is a planned increment of implementation in which related initiatives collectively move the enterprise from one architectural state toward the Target Architecture while delivering business value and establishing capabilities for subsequent transformation.
The phrase:
Wave 1 — Prove
Wave 2 — Reuse
Wave 3 — Scale
Wave 4 — Transform
is author's applied AI migration-wave model, not a TOGAF-defined sequence.
As an applied AI migration model, the roadmap can progressively increase the level of AI integration:
Wave 1 — Prove
Validate measurable business value while establishing delivery and evaluation practices.
Wave 2 — Reuse
Convert proven patterns into reusable enterprise capabilities.
Wave 3 — Scale
Extend AI across business domains using shared capabilities, integrations, governance, and operating practices.
Wave 4 — Transform
Move toward AI-native business processes, including controlled agentic workflows and intelligent cross-system orchestration where justified.
These waves are not rigid TOGAF stages.
They are an applied way of expressing how an enterprise can use architecture and migration planning to progressively increase capability.
Multiple initiatives may run concurrently.
The important point is that dependencies and transition states remain explicit.
The Architecture Roadmap as an Economic Instrument
An Architecture Roadmap should communicate more than technology change.
For each major migration increment, leadership should understand:
- what capability is introduced
- what business outcome it supports
- what dependencies it removes
- which initiatives can reuse it
- what investment is required
- what risks are reduced
- what legacy capability can eventually be retired
- what future options become available
The resulting relationship is:
Investment → Capability → Business Value → Enablement → Next Investment
This is the mechanism through which AI investment can compound.
A particularly useful transformation metric is:
What does it cost the enterprise to launch the next AI capability?
If every initiative costs approximately the same because the organization repeatedly rebuilds infrastructure, knowledge, governance, integration, and evaluation capabilities, the enterprise is accumulating applications without sufficient leverage.
If the marginal cost and delivery risk decline because capabilities are reusable, the enterprise is beginning to realize platform economics.
AI Migration Is Also an Operating-Model Migration
Technology alone does not create an enterprise AI capability.
The organization must also establish ownership for:
- AI products
- architecture
- evaluation
- model lifecycle
- knowledge quality
- AI security
- observability
- AI economics
- governance
- AI risk
- human oversight
A production AI architecture without a production operating model is incomplete transformation.
Every migration wave should therefore develop not only technology capability, but also the organizational capability required to operate it sustainably.
What the Enterprise Architect Should Ask
For each migration initiative, the Enterprise Architect should be able to answer:
Baseline
What capabilities exist today?
Target
What capabilities must exist in the future?
Gap
What prevents the enterprise from reaching the target?
Dependency
Which capabilities depend on others?
Transition
What intermediate architecture makes the change feasible?
Work Package
What logical group of changes creates each required capability?
Value
What business value does the work package create or enable?
Risk
What risks are introduced or reduced?
Resource
What skills, funding, technology, and organizational capacity are required?
Governance
How will architecture and implementation remain aligned?
Learning
What should the organization carry into the next migration cycle?
These questions shift the conversation from:
How many AI projects are we running?
to:
How is the enterprise's AI capability evolving?
The AI Migration Factory
At scale, organizations can institutionalize this discipline as an AI Migration Factory.
The factory is not a bureaucratic process. It is a reusable mechanism for moving from:
Opportunity → Architecture → Implementation → Production → Reuse → Scale
It can include:
- use-case intake
- value assessment
- architecture assessment
- dependency analysis
- data readiness
- risk assessment
- capability mapping
- migration-wave planning
- implementation governance
- benefits tracking
- lessons learned
- reusable architecture patterns
Each migration should improve the organization's ability to execute the next one.
That is organizational learning as an enterprise capability.
The Real Objective Is Not More AI
Enterprise AI transformation should not be measured primarily by the number of AI applications deployed.
The objective is:
More enterprise capability generated per unit of AI investment.
That requires a migration sequence in which every meaningful investment is evaluated for both its current value and its contribution to the future architecture.
The critical question is therefore not:
"Which AI project should we build next?"
It is:
"Which architectural change should happen next, and why is this sequence the most viable path toward the Target Architecture?"
That is migration thinking.
Conclusion: The Architecture of Compounding AI ROI
The most important decision in enterprise AI transformation may not be which use case to implement.
It may be what comes before it and what it enables afterward.
A well-designed migration sequence:
- connects business value to architecture
- exposes capability dependencies
- uses Transition Architectures where necessary
- converts proven patterns into reusable capabilities
- balances immediate value with future enablement
- manages risk progressively
- aligns implementation with the operating model
- reduces duplication and marginal delivery cost
- continuously incorporates organizational learning
This is the value of applying TOGAF's migration-planning discipline to enterprise AI.
The objective is neither to implement the easiest AI use cases first nor to build the largest AI platform upfront.
It is to create a deliberate architectural path in which each migration increment makes the next increment more feasible, more reusable, less risky, and economically stronger.
Enterprise AI transformation succeeds when the architecture of the migration itself becomes a source of compounding capability.
✍️ About the Author
Sanjoy Kumar Malik — Principal AI Architect, Enterprise AI Strategist, and Senior Engineering & Technology Leader with 20+ years of corporate IT experience and a broader 27+ year professional journey, spanning Enterprise Architecture, software architecture, cloud-native systems, engineering leadership, and AI architecture. He is a TOGAF 10 Certified Enterprise Architecture Practitioner and AWS Certified Solutions Architect – Professional.
Sanjoy focuses on translating business strategy and AI opportunity into coherent enterprise architecture and scalable engineering execution. He works at the intersection of business, technology, architecture, and AI, helping organizations establish the architectural foundations, technology capabilities, and engineering systems required to turn AI initiatives into production-grade, scalable, governed, and economically sustainable enterprise capabilities.
He is the creator of The 28-Category AI Architecture Decision Framework (28-CAADF), a systematic approach to making AI architecture decisions in an era where intelligence itself is becoming an architectural capability.