Cloud Migration Architecture in Sparx EA: Planning and Documenting Your Move to the Cloud
The short version: cloud migrations fail for the same reasons large transformations fail — the full inventory of what must move is unknown, dependencies are undocumented, owners are unclear, and the link between the technical migration and the business capability it supports is never made explicit. Enterprise architecture solves this. Used well, Sparx EA becomes the golden record for the migration — the single source of truth for what exists, what moves when, in what order, and why.
This piece walks the full cloud migration lifecycle in Sparx EA, from as-is landscape assessment through target architecture to migration-wave planning and program-level visibility.
The core problem cloud migration architecture solves
A typical migration starts with an application inventory — usually incomplete. It comes from a CMDB that hasn’t been updated in two years, a spreadsheet maintained by a retiring architect, or a discovery tool that finds the servers but cannot tell you which business processes depend on them. The result is wave plans built on incomplete information, surprises when systems that were not on the list turn out to be critical dependencies, and program delays that better governance would have avoided.
Sparx EA addresses this at the foundation level: a governed repository for the as-is application and infrastructure landscape, explicit dependency modeling between applications, data, and infrastructure, ArchiMate-based target architecture documentation, migration-pattern documentation linking each application to its approach, and a live connection to BI dashboards that gives program managers real-time visibility into progress.
The cloud migration lifecycle in Sparx EA
The lifecycle runs in four phases. Each produces an asset the next phase depends on.
As-is landscape assessment
Before planning, you need to know what you have. The as-is landscape is documented in an ArchiMate Application-layer model: application components for each system, application interfaces for the integration points, data objects linked to producing and consuming applications, technology nodes for current hosting, and business processes linked to the applications that support them. This model need not be built from scratch — connectors can pull application and infrastructure data from CMDB, ServiceNow, Azure Resource Manager, or AWS Config, and the architecture team then validates and enriches it. The critical output is the dependency map: which applications communicate, which data flows cross which boundaries, which share infrastructure, and which processes break if a system goes down. Wave planning is built on this.
Target architecture design
The cloud target is documented in ArchiMate’s Technology layer: regions and availability zones as Technology Nodes, virtual networks as infrastructure elements, compute resources as nodes with interfaces, managed services as Technology Services, and IAM in the security layer. MDG Technology extensions add cloud-provider-specific stereotypes — an Azure profile adds branded elements for AKS, API Management, Service Bus, and the rest — making target diagrams recognizable to cloud engineers without losing the underlying ArchiMate semantics. Each application is then linked to its cloud target state: what it becomes, which services it runs on, its performance and availability requirements, and its rollback position.
Migration pattern assignment
Each application gets a migration approach — the standard “6 Rs” (see the table below). In Sparx EA, each component is tagged with its pattern using a tagged value, which makes it straightforward to filter the inventory — “show all applications tagged Refactor” — and plan waves accordingly.
Wave planning and roadmap
Waves are planned around dependency clusters — groups of applications with heavy interdependencies that should move together. The dependency model makes this explicit: query it to identify which applications cannot move until their dependencies move first, model waves as ArchiMate Work Packages in the TOGAF Implementation and Migration viewpoint, and show them on an architecture roadmap timeline linked to the applications and capabilities they affect. The wave plan is not a standalone Gantt chart — when an application’s migration pattern changes, the update propagates through the model.
The migration patterns — the “6 Rs”
| Pattern | Description | Sparx EA documentation |
|---|---|---|
| Rehost (lift and shift) | Move to cloud infrastructure with no application changes | Tag the component with migration pattern, link to target VM or container spec |
| Replatform | Move with minor optimization (e.g., to a managed database service) | Document the delta between as-is and target configuration |
| Refactor / re-architect | Redesign the application to be cloud-native | Full target architecture including new component decomposition |
| Repurchase | Replace with a SaaS alternative | Document the replacement product, data migration, and integration changes |
| Retire | Decommission — no migration needed | Tag as retired with decommission date and data-retention requirements |
| Retain | Keep on-premises for now | Document reason (regulatory, dependency, cost) and review date |
BI integration: migration program dashboards
Architecture documentation is most valuable when it is visible to the program stakeholders who make decisions — not just the architects who maintain it. Connecting the Sparx EA repository to Power BI (and other BI platforms) enables a migration-status dashboard (applications by status — not started, in progress, completed, blocked — drawn live from the repository), wave-progress tracking, a dependency-risk view that surfaces blocked applications automatically, and a business-capability impact view showing which capabilities have full, partial, or no cloud coverage. Program managers get a live view without asking architects for status updates: architects update the model, the dashboards refresh. That feedback loop is what keeps a large migration visible and governed.
The Sparx EA “golden record”
When the golden record is in Sparx EA, dependency surprises are minimized and the organization has a durable record of what was decided, why, and when.
The highest-value positioning for Sparx EA is as the authoritative source all other program artifacts reference: the PMO wave plan references application IDs from the repository, the cloud team’s infrastructure-as-code references the documented target architecture, the security team’s risk assessments reference the asset inventory and dependency map, and the finance team’s business case references the application rationalization decisions. That matters for audit, for future migrations, and for governing the cloud estate once migration is complete.
A practical starting point
For organizations starting a migration, the first step is not cloud design — it is knowing what you have. Sparx Services supports this through a structured application rationalization process: automated discovery pulls existing inventory from CMDB, Azure Resource Manager, or AWS Config into the repository; the architecture team validates and enriches it, adding business-capability linkages and key dependencies; application owners and architects assign migration patterns in a structured workshop; dependencies are analyzed and wave groupings proposed; and a BI connection activates ongoing program visibility. This can be completed in four to eight weeks for a mid-size estate, producing a governed, queryable repository that serves as the foundation for the full program.
Frequently asked questions
Can Sparx EA model AWS, Azure, and GCP architecture specifically?
Yes, through MDG extension profiles. Custom profiles for AWS, Azure, and GCP add cloud-provider-specific diagram elements (EC2 instances, Azure App Services, GCP Cloud Run, and so on) as stereotypes within the ArchiMate Technology layer. Target diagrams use familiar cloud iconography while preserving the formal ArchiMate semantics that keep the model queryable and framework-compliant.
How does Sparx EA handle applications with complex integrations we don’t fully understand?
This is exactly the gap structured EA modeling is designed to expose. Connectors can pull integration data from API gateways, service meshes, and monitoring tools to populate interface diagrams, and the modeling process itself — asking architects and owners to validate the dependency map — surfaces integrations that exist but are not formally documented. Discovering unknown dependencies before migration starts is one of the highest-value outcomes of the EA phase.
We already have a migration tool (AWS Migration Hub, Azure Migrate). Why also use Sparx EA?
Migration tools track execution — replication status, cutover readiness, test results. Sparx EA documents migration architecture — why each application is moving as it is, what the target state looks like, how it connects to other systems, and the business rationale. They answer different questions, and the integration between them is where the two layers reinforce each other.
What happens to the Sparx EA model after migration is complete?
The cloud estate documented in Sparx EA becomes the as-is model for the next phase of evolution — further rationalization, modernization, or the next migration wave. Organizations that invest in architecture during migration do not discard that investment afterward; they have a governed model of their cloud estate to maintain and extend. That is the long-term value of treating migration as an architecture program, not a purely technical project.
Can AI assistants query the migration architecture in Sparx EA?
Yes — through the paid MCP tooling now available for Sparx EA (Sparx EA core has no built-in MCP server). With it connected, assistants such as Microsoft Copilot and Claude can query the repository in natural language: “Which applications in Wave 3 depend on systems not yet migrated?” or “How many applications are tagged Retire across the estate?” — without running custom scripts. Answer quality depends entirely on how well the repository is governed.
Make Sparx EA the golden record for your cloud move.
Talk to a practitioner about application inventory, dependency mapping, and program dashboards that keep a migration governed from day one.
Book a call →Keep reading
You might also be interested in
IT Modernization Architecture in Sparx EA
Planning legacy system transformation with a governed architecture model.
Read → InsightApplication Portfolio Management in Sparx EA
From spreadsheet to live intelligence — the inventory a migration depends on.
Read → For leadersConfigure the Solution
Inventory automation, dependency mapping, and dashboard configuration for migration programs.
See how → For architectsIT Architecture in Sparx EA
The discipline behind a governed, queryable estate model that survives the program.
Explore →