The project boundary is usually artificial
A cloud migration is often commissioned as an application project: move a defined workload, complete testing, switch production traffic and close the project. That boundary is convenient for funding and reporting. Technically, it is rarely real.
An application does not move to the cloud alone. It depends on identity, network routes, security controls, data, integration, monitoring, resilience, release processes and people who know how to operate it. Most of those capabilities are shared with other migrations. Some must exist before the first workload moves, while others only become effective when they are designed consistently across the estate.
My experience changed the unit of planning
Working across cloud migrations in a banking environment made this distinction practical rather than theoretical. Moving a credit platform to AWS, migrating a public website and coordinating adjacent infrastructure changes looked like separate deliveries on a plan. In execution, they repeatedly met the same enterprise questions: how environments connect, how access is controlled, where logs go, how data is protected, who accepts operational risk and who supports the service after release.
Treating each migration as independent would have forced every team to rediscover those questions, negotiate the same controls and create its own interpretation of the target environment. The apparent simplicity at project level would have produced duplication and inconsistency at enterprise level.
The landing zone is a shared product
Every workload needs a governed place to land. Account and subscription structures, network segmentation, identity federation, encryption, key management, audit logging, policy enforcement and environment separation cannot be designed independently for every application without creating fragmentation.
The landing zone should therefore be managed as a shared platform capability. Migration teams consume it, test it and expose gaps in it. A decision made for one workload can affect every workload that follows. That makes its roadmap, ownership and service levels portfolio concerns rather than background technical tasks.
Dependencies cross project plans
Applications communicate through APIs, queues, files, databases, identity providers and scheduled processes. Moving one side of an integration changes latency, routing, certificates, firewall rules, name resolution and failure behaviour. A migration can appear successful while breaking a process owned by another team.
Data creates another boundary problem. Replication, residency, retention, backup, recovery and reconciliation decisions often span systems. If each project optimises only for its own cutover, the organisation can end up with incompatible recovery objectives, duplicated data movement and unclear sources of truth.
Security and resilience cannot be local exceptions
Cloud security relies on consistent identity, least privilege, encryption, vulnerability management, configuration policy, security monitoring and incident response. A strong control applied to one application does not compensate for a weak shared identity or network model.
Resilience works the same way. Availability zones, regions, backup policies and disaster recovery procedures must connect to business impact and service dependencies. Recovering an application is of limited value if its identity service, integration path or critical data remains unavailable. Portfolio planning allows resilience to be tested as an end-to-end service rather than a collection of component claims.
Operations change with the architecture
A technically successful migration can still create an operational failure. Cloud services introduce new monitoring signals, cost behaviours, deployment patterns, support responsibilities and failure modes. Teams need runbooks, alert ownership, access procedures, capacity rules and a clear escalation model before production handover.
FinOps is also cumulative. One application's cloud cost may appear reasonable in isolation. Across a portfolio, inconsistent tagging, overprovisioning, unmanaged data transfer and duplicated services can make cost difficult to explain or control. Common standards create visibility before optimisation becomes an emergency.
Run migrations as waves within a portfolio
The answer is not one enormous programme that centralises every decision. Individual migration teams still need clear outcomes, accountable owners and the ability to deliver. The portfolio provides the shared architecture, dependency view, sequencing and governance that individual projects cannot create alone.
A practical model groups workloads into migration waves. The sequence reflects business criticality, technical affinity, shared dependencies, risk and the readiness of common capabilities. Early migrations deliberately test the platform and operating model. Lessons are converted into reusable patterns before later waves scale them.
What portfolio governance should control
Portfolio governance should control the decisions that affect more than one migration: target patterns, landing-zone readiness, shared security controls, dependency resolution, data and integration strategy, operational acceptance, migration sequencing and aggregate risk. It should also expose when a project is being asked to move before the enterprise capabilities it depends on are ready.
This is why cloud migration cannot be managed credibly as a series of isolated infrastructure projects. The workload is the unit of movement. The portfolio is the unit of transformation.