For years, cloud migration had a familiar business case. Close the data center, stop buying hardware, pay only for what you use. Many organizations moved their applications as they were and called the job done.
AI has changed the brief. Leaders now ask a second question alongside "can we run this in the cloud?" They ask whether the move will let them use AI on their own data. A system that was simply lifted into the cloud usually cannot. Its data is still locked in old formats and separate stores. Its integrations are still brittle. Its costs are still hard to see.
Lift and shift move the problem. It does not solve it.
Let's cover how to plan a migration that leaves the business ready for AI. That means deciding what to move and how, modernizing the data, planning for AI cost, and building the delivery and reliability foundation the new environment needs.
Why AI Changed the Brief for Cloud Migration
Migration relocates a system. Transformation changes how it runs. For a long time, relocation was enough. AI is what makes the difference matter.
AI depends on data more than any workload before it. Gartner found that 63% of organizations either lack or are unsure they have the right data management practices for AI. It predicts that through 2026, organizations will abandon 60% of AI projects that are not supported by AI-ready data. Gartner also points to data collected in silos across many systems as part of the problem.
A migration is the one moment when every system, data store, and integration is open for change at once. If the plan only aims to move things, that moment is wasted.
Here is what AI needs from the cloud, and what a simple lift and shift tends to leave behind.
| What AI Needs | What a Lift and Shift Usually Leaves |
|---|---|
| Connected, current data that can be governed and reused | The same separate databases, now on rented servers |
| Compute that scales up for AI work and back down after | Fixed virtual machines sized for the old data center |
| Clean interfaces so AI can read from and act in systems | The same tightly coupled applications, with few usable APIs |
| Identity, access and audit controls defined consistently | Old permissions carried over system by system |
| Clear cost per workload and per outcome | A bigger bill with little sense of what drives it |
None of these means that every system must be rebuilt. It means the migration plan has to know which systems AI will depend on and treat those differently.
Decide Workload by Workload, Not Estate by Estate
The most common migration mistake is applying one approach to everything. Lifting the whole estate is fast and cheap up front. It is also often why cloud bills end higher than the data center they replaced.
A better plan gives every system its own decision, usually framed as the seven R's. The six below cover most decisions; the seventh, relocating, is a variant of rehosting. AI adds one question to each decision: will AI need to read from this system, or act inside it?
| Path | What It Means | When It Fits |
|---|---|---|
| Retire | Switch the system off | Little used or duplicated by another system. Frees budget for the rest. |
| Retain | Leave it where it is for now | Regulatory limits, recent investment, or little relevance to AI plans |
| Rehost | Move it as it is | Stable systems AI will not depend on, or a hard deadline to exit a data center |
| Replatform | Move it with targeted changes, such as a managed database | Systems whose data AI will need, where a full rebuild is not justified |
| Repurchase | Replace it with a SaaS product | Standard functions that do not set the business apart |
| Refactor | Rebuild it for cloud-native services | Core systems that differentiate the business and that AI will rely on |
Retiring or retaining a system is a valid result, not a failure of ambition. Moving workloads that should have stayed put is a common reason organizations later move them back.
This per-system decision is where a cloud migration and transformation program should begin. Every application gets mapped, its dependencies traced, and its path chosen before anything moves.
Move the Data, Not Just the Applications
Migration plans usually center on applications. For AI, the data decides the outcome. An application can be moved perfectly and still leave its data scattered, inconsistent and impossible to use.
Migration is the cheapest moment to fix that. The data is already being extracted, converted, and validated. Doing the cleanup in flight costs far less than reopening the estate a year later.
The work follows the same logic Gartner sets out for AI-ready data.
- Start From the Use Cases: Identify which data the planned AI work will need and prioritize those sources in the migration sequence.
- Consolidate and Define: Merge duplicate stores, agree on definitions for shared records such as customer or order, and name an owner for each source.
- Govern Sensitive Data on the Way In: Classify personal, regulated and confidential fields, and set access rules as part of the landing zone rather than afterward.
- Build Pipelines, Not Exports: Replace one-off data dumps with pipelines that keep AI systems fed with current data.
- Make Quality Visible: Add monitoring, so data problems are spotted before a model or a report relies on them.
None of this needs to delay the migration. It needs to be in the plan from the start, with data moving in the same waves as the applications that own it. Turning disconnected data into something AI can use is the focus of our data intelligence work.
Plan for AI Cost Before It Arrives
Most migration business cases compare today's infrastructure to spend with the projected cloud bill for the same workloads. AI adds a cost line that model does not cover. Model usage is billed by volume, and computing for AI work can spike quickly. A cloud estate with no cost discipline will feel that first.
Finance teams have noticed. The State of FinOps 2026 survey found that 98% of FinOps practitioners now manage AI spend, up from 31% two years earlier. Many organizations are also being asked to fund AI from efficiency gains elsewhere in their technology budget.
That makes cost-a design decision, not an afterthought.
- Model Run Costs Per Workload Before the Move: Project what each system will cost in the cloud against what it costs today, so the business case holds after the first invoice.
- Tag Everything from Day One: Every resource belongs to a team, product, and environment, so spending can be traced to the people who control it.
- Measure Cost Per Outcome: Cost per transaction, per customer or per AI-assisted case tells leaders far more than a monthly total.
- Turn Savings into an AI Budget: Rightsizing, scheduling and committed-use discounts free real money. Ring-fencing it for AI work makes the trade-off visible.
Cost governance does not end at cutover. It becomes an ongoing discipline, which is the focus of our cloud optimization work.
Build the Delivery and Reliability Foundation As You Go
A migration changes where software runs. It should also change how software is delivered and operated. Teams that move to the cloud but keep manual releases and old monitoring carry their slowest habits into a faster environment.
AI raises the stakes. Google's 2025 DORA research found a direct link between the quality of an organization's internal platform and its ability to get value from AI. The foundation is worth building while the environment is new.
- Infrastructure as Code. Landing zones, networking, identity and platform configuration defined in code, version controlled and reproducible. Environments stop drifting, and audits get easier.
- Automated Delivery Pipelines: Every change is built, tested, scanned, and deployed in the same way. This is what lets teams release AI features often without breaking what already works.
- Observability from the first workload. Logs, metrics, and traces in place before cutover, so the team can see how the new estate behaves under real traffic.
- Reliability targets agreed up front. Service level objectives tied to customer journeys define what "working" means before anyone must argue about it during an incident.
- Clear operational ownership. Runbooks and on-call responsibility handed over with the system, not discovered after the first outage.
Our DevOps engineering work builds the delivery side of this foundation. Cloud reliability and operations takes ownership of keeping it running once the migration is done.
What a Migration Plan Built for AI Looks Like
A migration built for AI does not need extra stages. It needs a different question asked at each one: what will AI need from this?
Fulcronix runs cloud migrations on The Pivot. Each stage has a defined output, and each one settles part of the AI readiness question.
| Stage | What Happens | Output | What It Settles for AI |
|---|---|---|---|
| Discover | Application inventory, dependency mapping, workload profiling and a current-cost baseline | A documented estate with a path for each system | Which systems and data AI will depend on |
| Define | Migration strategy, wave sequencing and the financial case | A roadmap with a cost model behind it | Wave order follows AI priorities, and AI cost is in the model |
| Design | Target architecture, landing zones, networking, identity and security controls defined as code | A platform design reviewed before anything moves | Data access and governance designed for AI from the start |
| Build | Workload and data migration in waves, validated against production behavior | Migrated workloads running under real traffic | Data cleaned and connected as it moves |
| Launch | Cutover, validation under load and retirement of the source environment | One running estate with the legacy footprint retired | Monitoring and reliability targets live from day one |
| Evolve | Handover to ongoing cost governance and operations | Costs and reliability managed as usage grows | AI spend and performance tracked against outcomes |
The team that plans the migration is the team that runs it, so nothing is lost between a strategy deck and the engineers doing the work. Landing zone code, runbooks, and documentation end up in the client's own repositories. The estate stays understandable after the project ends.
Seven Questions to Ask Before You Approve a Migration Plan
These questions work for a plan written in-house or one proposed by a partner. Each one points to a decision that is far cheaper to make before the first workload moves.
- Does Every System Have Its Own Path? And is there a reason written down for each one, including the ones being retired or retained?
- Which Systems and Data Do Our AI Plans Depend On? Are they early in the migration sequence, or left until last?
- Is Data Cleanup Part of the Plan? Or has consolidation, ownership, and governance been deferred to a later project?
- Does the Business Case Include AI Run Cost? Will the numbers still hold after the first full month of cloud invoices?
- Are Landing Zones, Identity and Security Controls Defined in Code? Or will they be configured by hand and drift over time?
- Will Monitoring and Reliability Targets Be Live Before Cutover? Or will the team find out how the new estate behaves from its customers?
- Who Owns Cost and Operations the Day After the Migration Ends? Is that named in the plan, with runbooks to match?
If a plan cannot answer most of these, it describes a move, not a transformation.
Move Once, and Move with Purpose
Most organizations move their core systems to the cloud only once. The plan made now decides whether the new estate is ready for the AI to work ahead, or whether it needs another expensive round of change in two years.
Treat the migration as the moment to decide what each system is for, what data AI will need, and what it will cost to run. The move itself is the easy part.
If you are planning a migration, or trying to recover one that stalled, start with a readiness assessment. You get a path for every system and a run-cost model against your current infrastructure spend. Book a readiness assessment or see how we run cloud migrations.
