Cloud migration programs fail for many of the same reasons other large IT transformation programs fail: the full inventory of what needs to move is unknown, dependencies are undocumented, owners are unclear, and the relationship between the technical migration and the business capability it supports is never made explicit. Enterprise architecture solves this. Sparx EA, used well, becomes the “golden record” for the cloud migration — the single source of truth for what exists, what moves when, in what order, and why.
This article explains how Sparx EA supports the full cloud migration lifecycle, 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 cloud migration program starts with an application inventory. That inventory is usually incomplete: it comes from a CMDB that has not been updated in two years, a spreadsheet maintained by a retiring architect, or an automated discovery tool that finds the servers but cannot tell you which business processes depend on them.
The result is migration 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 could have been avoided with better architecture governance.
Sparx EA addresses this at the foundation level by providing:
- A governed repository for the as-is application and infrastructure landscape
- Explicit dependency modeling between applications, data, and infrastructure
- ArchiMate-based target architecture documentation for the cloud environment
- Migration pattern documentation that links each application to its migration approach
- A live connection to BI dashboards (via EA GraphLink and Power BI) that gives program managers real-time visibility into migration progress
The Cloud Migration Lifecycle in Sparx EA
Phase 1: As-Is Landscape Assessment
Before planning a migration, you need to know what you have. In Sparx EA, the as-is landscape is documented in an ArchiMate Application layer model:
- Application components for each system (ERP, CRM, custom applications, middleware)
- Application interfaces documenting the integration points between systems
- Data objects linked to the applications that produce and consume them
- Technology nodes representing the current hosting infrastructure (on-premises servers, data centre racks, network components)
- Business processes linked to the applications that support them
This model does not need to be built from scratch. EA GraphLink can pull application and infrastructure data from existing sources — CMDB, ServiceNow, Azure Resource Manager, AWS Config — and populate the repository. The architecture team then validates, enriches, and governs the resulting model.
The critical asset produced at this stage is the dependency map: which applications communicate with which, which data flows cross which boundaries, which applications share infrastructure, and which business processes would be disrupted if a particular system were unavailable. This dependency map is what migration wave planning is built on.
Phase 2: Target Architecture Design
The cloud target architecture is documented in ArchiMate’s Technology layer:
Cloud infrastructure modeling:
- Cloud regions and availability zones as ArchiMate Technology Nodes
- Virtual networks (VNets, VPCs) as infrastructure elements
- Compute resources (VMs, containers, serverless functions) as nodes with interfaces
- Managed services (Azure SQL, AWS RDS, GCP Pub/Sub) as Technology Services
- Identity and access management as Technology Services in the security layer
MDG extensions for cloud providers: Sparx EA’s MDG technology allows custom stereotypes for cloud-provider-specific services. An Azure MDG profile, for example, adds Azure-branded diagram elements for Azure Kubernetes Service, Azure API Management, Azure Service Bus, and others — making target architecture diagrams immediately recognizable to cloud engineers and program stakeholders without losing the underlying ArchiMate semantics.
Application target state documentation: Each application in the as-is inventory is linked to its cloud target state: what it becomes in the target architecture, which cloud services it runs on, what the performance and availability requirements are, and what the rollback position is.
Phase 3: Migration Pattern Assignment
Each application needs a migration approach. The standard patterns — often called the “6 Rs” or “5 Rs” — are:
| Pattern | Description | Sparx EA documentation |
|---|---|---|
| Rehost (Lift and Shift) | Move the application to cloud infrastructure with no changes to the application | Tag the application component with migration pattern, link to target VM or container specification |
| Replatform | Move with minor optimisation (e.g., move to managed database service) | Document the delta between as-is and target application configuration |
| Refactor / Re-architect | Redesign the application to be cloud-native | Full target architecture documentation including new component decomposition |
| Repurchase | Replace with a SaaS alternative | Document the replacement SaaS product, data migration requirements, and integration changes |
| Retire | Decommission — no migration needed | Tag the application as retired with decommission date and data retention requirements |
| Retain | Keep on-premises for now | Document reason for retention (regulatory, dependency, cost) and review date |
In Sparx EA, each application component is tagged with its migration pattern using a tagged value. This makes it straightforward to filter the application inventory by pattern — “show all applications tagged as Refactor” — and to plan waves accordingly.
Phase 4: Wave Planning and Roadmap
Migration waves are typically planned around dependency clusters: groups of applications that have heavy interdependencies and should move together. Sparx EA’s dependency model makes wave planning explicit:
- Dependency analysis: Query the model to identify which applications cannot move until their dependencies have moved first
- Wave groupings: Model migration waves as ArchiMate Work Packages in the TOGAF Implementation and Migration viewpoint
- Roadmap timeline: ArchiMate’s roadmap view shows migration waves on a timeline, linked to the applications they include and the business capabilities they support
- Risk documentation: Each wave includes documented risks, dependencies on other programs, and owner assignments
The wave plan in Sparx EA is not a standalone Gantt chart — it is linked to the architecture. When an application’s migration pattern changes (because a Lift and Shift assessment reveals it is more complex than expected), the wave plan update propagates through the model.
EA GraphLink + Power BI: Migration Program Dashboards
Architecture documentation in Sparx EA is most valuable when it is visible to the program stakeholders who need to make decisions — not just the architects who maintain it.
EA GraphLink connects the Sparx EA repository to Microsoft Power BI (and other BI platforms). For a cloud migration program, this enables:
- Migration status dashboard: Real-time view of applications by migration status (Not started, In progress, Completed, Blocked) drawn live from the repository
- Wave progress tracking: Which applications in each wave have completed migration versus planned
- Dependency risk view: Applications that are blocked by an outstanding dependency, surfaced automatically when the architecture model is updated
- Business capability impact view: Which business capabilities have full cloud coverage, partial coverage, or no cloud migration plan yet — giving business stakeholders a capability-level view rather than an application-level view
Program managers get a live view of migration progress without asking architects for status updates. Architects update the model; the dashboards refresh. This is the feedback loop that keeps a large migration program visible and governed.
The Sparx EA “Golden Record” for Cloud Migration
The highest-value positioning for Sparx EA in a cloud migration program is as the golden record — the authoritative source of truth that all other program artifacts reference. This means:
- The migration wave plan in the PMO tool references application IDs from the Sparx EA repository
- The cloud team’s infrastructure-as-code templates reference the target architecture documented in Sparx EA
- The security team’s risk assessments reference the asset inventory and dependency map from Sparx EA
- The finance team’s business case references the application rationalization decisions documented in Sparx EA
When the golden record is in Sparx EA, architectural decisions are governed, dependency surprises are minimized, and the organization has a durable record of what was decided, why, and when — which matters for audit, for future migrations, and for the ongoing governance of the cloud estate once migration is complete.
Practical Starting Point: The Application Rationalization Workbook
For organizations starting a cloud migration, the practical first step is not cloud architecture design — it is knowing what you have. Sparx Services supports this through a structured application rationalization process:
- Automated discovery: EA GraphLink pulls existing application inventory from CMDB, Azure Resource Manager, or AWS Config into the Sparx EA repository
- Validation and enrichment: Architecture team validates the inventory, adds business capability linkages, and documents key dependencies
- Pattern assignment workshop: Application owners and architects assign migration patterns (Rehost, Replatform, Refactor, Repurchase, Retire, Retain) using a structured assessment
- Wave planning: Dependencies are analyzed, wave groupings are proposed, and the migration roadmap is documented in ArchiMate
- Dashboard activation: EA GraphLink connects the repository to Power BI for ongoing program visibility
This process can be completed in four to eight weeks for a mid-size application estate, producing a governed, AI-queryable architecture repository that serves as the foundation for the full migration program.
Frequently Asked Questions
Can Sparx EA model AWS, Azure, and GCP architecture specifically? Yes, through MDG extension profiles. Custom MDG profiles for AWS, Azure, and GCP add cloud-provider-specific diagram elements (EC2 instances, Azure App Services, GCP Cloud Run, etc.) as stereotypes within the ArchiMate Technology layer. This allows target architecture diagrams to use familiar cloud-provider iconography while preserving the formal ArchiMate semantics that make the model queryable and framework-compliant.
How does Sparx EA handle applications that have complex integrations we don’t fully understand? This is exactly the gap that structured EA modeling is designed to expose. EA GraphLink can pull integration data from API gateways, service meshes, and monitoring tools to populate interface diagrams. The modeling process itself — asking architects and application owners to validate the dependency map — surfaces the integrations that exist but are not formally documented. The discovery of unknown dependencies before migration starts is one of the highest-value outcomes of the EA phase of a cloud program.
We already have a migration tool (AWS Migration Hub, Azure Migrate). Why do we also need Sparx EA? Migration tools track migration execution — server 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 what the business rationale is. They address different questions. The integration between them — with EA GraphLink pushing application status from Sparx EA to feed BI reporting — is the point at which the two layers reinforce each other.
How do we keep the architecture model current as the migration progresses? The model is updated by the architecture team as applications complete migration. EA GraphLink automations can flag when cloud infrastructure discovered in Azure or AWS does not have a corresponding element in the Sparx EA repository — alerting architects to applications that were migrated without being tracked. This governance loop is what keeps the model accurate as a dynamic program progresses.
What happens to the Sparx EA model after the migration is complete? The cloud estate documented in Sparx EA becomes the as-is model for the next phase of evolution — future application rationalization, further modernization, or the next migration wave. Organizations that invest in architecture during cloud migration do not discard that investment post-migration; they have a governed model of their cloud estate that can be maintained and extended. This is the long-term value of treating the migration as an architecture program rather than a purely technical project.
How large an application estate can Sparx EA handle for cloud migration? Sparx EA has been used to manage application inventories of thousands of applications. Repository performance at scale depends on database configuration (SQL Server or Oracle backend is recommended for large repositories) and modeling discipline (avoiding unnecessary duplication and maintaining a clean package structure). Sparx Services can advise on repository architecture for large-scale migration programs.
What is the Connect service’s role in a cloud migration program? The Connect service covers EA data integration — specifically the connections between the Sparx EA repository and external data sources (CMDB, cloud provider APIs) and reporting tools (Power BI, Tableau). For a cloud migration program, Connect delivers the application inventory automation (pulling from existing sources into Sparx EA) and the program dashboard (pulling from Sparx EA into Power BI for stakeholder reporting).
Can AI assistants query the migration architecture in Sparx EA? Yes. Via the Sparx EA MCP server, AI assistants including Microsoft Copilot and Claude can query the repository in natural language. For a cloud migration program, this means program managers can ask questions like “Which applications in Wave 3 have dependencies on systems not yet migrated?” or “How many applications are tagged as Retire across the entire estate?” without running custom scripts — the AI assistant interrogates the model directly.
Start the Migration Architecture Engagement
If your organization is planning a cloud migration and wants to establish architecture governance from the start, the Connect service provides the foundation: application inventory automation, dependency mapping, and program dashboard configuration.
CTA: Connect — Architecture data integration for cloud migration programs