Leading a 3-Data-Center AWS Migration Without Information About Infrastructure

The challenge

The data centers were approaching operational risk: if the migration was delayed, partial or full infrastructure failure was a real possibility. Some applications ran only in production, with no staging environment and no fallback, so every migration decision carried direct business risk. There was no room for long analysis cycles or experimentation.

The infrastructure was not documented. Years of staff turnover had erased institutional knowledge, application ownership was unclear, and critical dependencies existed only in the heads of people who had already left. Before migration could begin, the environment had to be mapped again from scratch.

It was also one of the largest and most complex cloud migration initiatives delivered within Endava. Several parallel teams migrated logical application groups independently, under the same technical and timeline constraints. Keeping the architecture consistent across them, managing dependencies between groups and staying aligned with C-level business priorities was the structural challenge of the programme.

My task: lead one of the migration teams through the most complex application groups, and as a member of the central Architecture Board, keep the target architecture, migration patterns and cross-team decisions consistent.

How is a large migration to AWS organised?

AWS describes a large migration in three phases. In the assess phase, the business case is built and readiness is checked. In the mobilize phase, the organisation prepares the landing zone, security and the operating model. In the migrate and modernize phase, servers and applications move in batches called waves, often through a repeatable “migration factory” of standard procedures and automation. For each application the team chooses one of seven strategies, the 7 Rs: retire, retain, rehost (lift and shift), relocate, repurchase, replatform or refactor. After each cutover, the team watches the applications closely for a short period, called hypercare.

What I did

1. Rebuilt the map of an undocumented environment

   Before any migration wave could run, the environment had to be understood. The assessment phase was a systematic analysis of the full infrastructure and all its applications: identifying logical application groups, mapping dependencies, including hidden and undocumented ones, and clarifying ownership, both current and after the migration. Discovery then continued throughout the programme, because migrating one group often revealed dependencies into groups not yet assessed.

   Technical details

   • Discovery output: logical application groups, a dependency map that included hidden dependencies, and a named owner for each application before and after the migration.

2. Led a migration team through the full migration lifecycle

   I led one of the parallel migration teams, with direct responsibility for planning and executing the most complex application groups. For each application this covered discovery and dependency mapping, choosing a migration strategy (rehost, replatform, refactor, retire and the other Rs), detailed migration planning, a test catalog, risk assessment, rollback planning, execution and hypercare.

   Technical details

   • Single-production applications: some applications had no staging environment, so a failed migration meant a production incident. For these, rollback procedures were detailed, execution windows precise and recovery steps tested in advance.
   • Test catalog: the list of checks run before and after each cutover to confirm that an application works as expected.

3. Kept the architecture consistent across parallel teams

   At the same time I was a member of the central Architecture team, working on target architecture decisions, migration patterns and cross-team consistency. We made sure that individual team migrations did not create enterprise-level dependency conflicts or drift from the agreed target architecture: wrong dependency sequencing, inconsistent naming and AWS account structures, or incompatible network designs. Working at team level and at board level at once meant cross-team dependency issues could be resolved before they blocked the programme.

4. Reported to the C-level and managed cloud costs from day one

   I worked directly with the client’s and Endava’s C-level management: translating architecture choices into business terms, reporting programme progress, and escalating and resolving risks at enterprise level. I was also responsible for cost efficiency throughout. Resources were evaluated and right-sized continuously during the migration, so cost control was part of the migration pattern from the start.

   Technical details

   • Why cost control belongs in the migration: in Flexera’s 2026 State of the Cloud report, organisations estimate that 29% of their cloud infrastructure and platform spend is wasted.

Results

In about 1.5 years the programme delivered:

• A full migration of the client’s workloads from three European data centers to AWS.
• All three data centers exited and decommissioned.
• Zero production outages during the migration, including applications that had only a production environment.
• A reliable map of a previously undocumented environment: application groups, dependencies and owners.
• Consistent target architecture and migration patterns across parallel teams.
• A team and a method that the next migration reused: the Orange Cloud to AWS migration took six months.

What I learned

You cannot migrate what you don’t understand.

In large organisations with years of staff turnover, undocumented systems and inherited infrastructure, the gap between what an organisation thinks it owns and what it actually runs can be enormous. Discovery is the most critical work of the migration, and it starts before the first wave. Every dependency missed in the assessment becomes a production incident during execution, and every application without a clear owner becomes an escalation that stalls a migration wave. With parallel teams, a shared and verified map of the environment is also the only way to avoid conflicts that grow faster than any single team can resolve them.

Evidence and further reading

• Related projectMigrating a French enterprise from Orange Cloud to AWSThe next chapter of the programme: the same team and method, a harder source platform.
• Related projectBuilding a Cloud Center of Excellence from zeroOne set of cloud standards for a whole company.
• Service · this siteCloud migration consultingHow I plan and lead migrations to the cloud.

Delivered as Senior Infrastructure Architect (Manager) at Endava, where I held the highest technical grade in Endava Poland, was a Cloud Champion, led the AWS Cloud Center Poland, contributed to Endava’s Centre of Excellence in Cloud Migration and mentored the LatAm infrastructure practice. AWS Solutions Architect certified.

Skills and technologies

• Data center migration
• Data center exit
• AWS migration
• Large-scale migration
• Discovery and assessment
• Application dependency mapping
• Migration waves
• 7 Rs migration strategies
• Rollback planning
• Test catalogs
• Hypercare
• Architecture Board
• Architecture governance
• AWS account and network structure
• Cloud cost optimisation
• C-level stakeholder management
• Team leadership
• AWS Solutions Architect

← All projects