AI9 min read
What is enterprise AI architecture?
The difference between a successful pilot and a production AI capability is rarely the model. It is the architecture around it. Here is what that architecture contains and which decisions matter.
Cloud
Cloud modernization strategy: how to modernize legacy systems without stopping the business
Moving to the cloud is the easy part. Making legacy systems cheaper to run and faster to change is the goal. A strategy built from assessments and migrations in real enterprise environments.
Published on 9 min readby Carlos Medger
Key takeaways
- Assess the portfolio first: value, risk, dependencies and modernization potential per workload, not a blanket decision.
- Build the landing zone before the first wave. Identity, network, security and cost controls are cheaper to do once.
- Integration middleware is usually the critical path. Plan it explicitly.
- Modernize selectively: rehost the stable, replatform the expensive, refactor the strategic, retire the redundant.
Start with the portfolio, not the platform
Most cloud programs begin with a provider decision and a date. The better starting point is an inventory of applications, databases, integrations and the dependencies between them, scored by business value, operational risk, cost and how much would change if they were modernized. That assessment produces a different answer for each workload, which is what a realistic plan needs.
One decision per workload
The classic options still apply, and the point is to choose deliberately:
- Rehost: move as is. Right for stable workloads with low change frequency where speed of exit matters.
- Replatform: move to managed services such as managed databases, containers or app platforms. Right for workloads where operations cost dominates.
- Refactor: change the architecture, typically toward services, events and serverless. Right for strategic applications that need to change quickly.
- Repurchase: replace with SaaS. Right when the capability is commodity.
- Retire: decommission. Right more often than teams expect once the inventory is honest.
- Retain: keep on premise for now, with hybrid connectivity. Right for regulated or uneconomical workloads.
Build the foundation once
A landing zone is the set of accounts or subscriptions, identity, network topology, security baselines, policies, logging and cost management that every workload inherits. Building it before the first wave prevents the accidental estate that becomes expensive to fix. Infrastructure as code and CI/CD pipelines belong here too, because they are how waves become repeatable.
Integration is the critical path
In enterprise migrations, the hardest dependency is rarely the application server. It is the integration middleware: IBM Integration Bus, Oracle SOA Suite, MQ queues, file transfers and the batch jobs nobody documented. Every application wave touches interfaces that other applications depend on.
Plan integration as its own workstream. Options include running the existing platform in the cloud, moving to a managed integration service, or modernizing to APIs and events behind stable contracts so applications can move independently. The strangler approach, migrating interface by interface with parallel runs, keeps the business running throughout.
Waves, validation and rollback
- Group workloads into waves by dependency and risk, starting with low-risk, self-contained applications to prove the pipeline.
- Validate performance, security posture and cost after each wave against the assessment baseline.
- Keep rollback plans and data synchronization until the cutover is confirmed.
- Update runbooks and monitoring as part of the wave, not after.
Cost: design it in
Cloud bills grow when architecture ignores them. Rightsizing, serverless and managed services where they fit, reserved capacity for stable workloads, tagging from day one and a monthly FinOps review with workload owners are the practices that keep spend proportional to value. Cost should be a design criterion at assessment, not a surprise after the first invoice.
Where AI fits
Modernization creates the foundation AI needs: APIs that expose legacy capabilities, a governed data platform, identity and security baselines. Sequencing those into the early waves is what makes AI initiatives viable later. Generative AI also helps the modernization itself: documenting undocumented code and interfaces, generating tests and accelerating migrations of integration flows, always with engineers validating the output.
Frequently asked questions
Should we migrate everything at once?
No. Waves sequenced by dependency and risk reduce the blast radius, let the team learn and keep the business running. A big-bang migration concentrates every risk on one weekend.
How do we choose between Azure, AWS and Google Cloud?
By existing contracts and skills, the workplace and data platform footprint, and specific service needs. All three are enterprise-grade. Spreading thinly across providers without a reason increases cost and complexity.
What about systems that cannot move?
Retain them with hybrid connectivity and expose their capabilities through APIs so modern applications can use them. Plan their future in the roadmap rather than leaving them out.
Insights
Keep reading
AI11 min read
How to build an enterprise RAG architecture
RAG is simple to demo and hard to run. This guide walks through the components of a production retrieval-augmented generation architecture and the decisions that separate a reliable system from a chatbot that hallucinates politely.
AI8 min read
AI agents vs traditional automation: when to use each
Agents are not a replacement for every workflow engine and RPA bot. They are a new tool for a specific class of work. Knowing which class is the difference between a reliable operation and an expensive experiment.
Want to apply this to your architecture?
Talk to an architect about your systems, your data and what it would take to execute.