Cloud Migration: Architecture & Approach

In short: Cloud migrations rarely fail on the technical act of moving things — they fail on missing architecture. Lift-and-shifting workloads into the cloud without a target picture carries security gaps, uncontrolled costs and dependencies along for the ride. A sustainable cloud migration therefore starts with architecture: a clean target environment and a deliberate decision on how each application is moved. This guide explains our approach — from the target architecture and landing zone, through the 6-R strategy per application, to a low-risk migration roadmap.

The essentials at a glance

• A cloud migration is an architecture and portfolio decision, not a pure infrastructure project.
• The landing zone (network, identity, security, cost governance) is the foundation — before the first migration.
• The 6-R strategy decides per application: Rehost, Replatform, Refactor, Repurchase, Retire or Retain.
• A good migration roadmap sequences by business value and risk — not technical convenience.

Why architecture before migration?

The most common mistake is treating the cloud as “another data centre” and simply relocating servers. This works short-term but creates problems quickly: without a well-designed network and identity structure, security risks emerge; without cost governance, spending explodes; and without a target picture, existing technical debt is carried unchanged into the cloud.

An architecturally grounded cloud migration is typically warranted when data centre or hardware lifecycles expire, when scalability and resilience are required, during post-merger consolidations — or when an existing landscape is being modernised. It is the core of a solid cloud architecture & migration engagement and requires the same lead time as any other architecture programme.

Cloud migration: the approach

Step 1 — Inventory and cloud readiness assessment

We begin by documenting the application and infrastructure landscape: dependencies, data flows, licensing and lifecycle status, operating costs and compliance requirements. Where a reliable inventory is missing, an IT landscape analysis or a cloud migration assessment is the usual starting point. The output is a fact-based cloud readiness rating per application.

Step 2 — Design the target architecture and landing zone

Now the target architecture takes shape: the landing zone with its account/subscription structure, network segmentation, identity and access management, security guardrails, logging and cost governance. This baseline is built once, properly, and then reused — it determines whether the migration scales safely and in a controlled way later, or collapses into sprawl.

Step 3 — Apply the 6-R strategy per application

For each application we make a deliberate migration decision using the 6 Rs:

The value of the model: an opaque landscape becomes a clear portfolio decision — every application gets a reasoned direction instead of a blanket “everything to the cloud”.

Step 4 — Embed security, compliance and cost governance

Security and costs are not afterthoughts — they are part of the architecture. We embed identity and access concepts, encryption, network security and compliance requirements (such as data residency) directly in the target architecture, and from the outset establish FinOps guardrails — budgeting, tagging and cost transparency — so cloud spend remains controllable.

Step 5 — Migration roadmap and waves

The 6-R decisions and dependency map produce a phased migration roadmap, sequenced by business value, risk and technical complexity. We start with low-risk, instructive workloads (to establish patterns and automation) and work towards the business-critical systems — each wave with a defined test, cutover and rollback plan.

Step 6 — Migrate, validate and optimise

In execution we migrate wave by wave, validate function, performance and security against defined criteria, and optimise afterwards: right-sizing resources, controlling costs and — where sensible — incrementally modernising previously rehostd workloads. The migration does not end with the move, but with a production-ready, optimised target environment.

Which metrics matter?

We steer the migration through a small number of meaningful metrics:

• Migration progress — share of workloads moved per wave.
• Cloud costs vs. business case — is spend tracking within the planned envelope?
• Availability and performance — are migrated services meeting their commitments?
• Security and compliance findings — is the target environment remaining clean?
• Right-sizing degree — how efficiently are resources provisioned?

Typical outcomes

An architecturally grounded cloud migration delivers a reusable landing zone, a documented 6-R decision per application, a low-risk migration roadmap and a production-ready, cost-optimised target environment. The benefit: improved scalability and resilience, controlled costs rather than cloud-bill shock, and a modernised landscape — rather than merely relocated technical debt.

Methodological foundation

We work architecturally on the basis of TOGAF and model target and transition architectures in ArchiMate where appropriate — so the migration remains traceable and connected to the broader architecture work. Where the application landscape should be rationalised before migration, an application portfolio analysis is the natural precursor — it answers which systems should migrate at all.

Conclusion

A cloud migration is first and foremost an architecture task. The landing zone provides the secure foundation, the 6-R strategy the clear decision per application, and the phased roadmap the low-risk path. Organisations that think through the target architecture before the first move migrate faster, more securely and more cheaply — and do not arrive with the same technical debt in a more expensive environment.

Approach your cloud migration with a solid architectural foundation? We guide you from target architecture through 6-R decisions to a production-ready migration roadmap. → Portamus Cloud Architecture & Migration