One of the world’s largest digital real estate technological companies needed to exit 3 European data centers and migrate entirely to AWS – under operational pressure, with incomplete documentation, lost institutional knowledge, and teams who had inherited systems nobody fully understood. I joined from day one as Lead Infrastructure Architect for one of the migration teams and as a member of the central Architecture Board, working directly with client C-level leadership throughout.
Enterprise AWS migration
3 data centers
Architecture board
Discovery-first migration
Single-prod environments
C-level stakeholder
3 data centers
Architecture board
Discovery-first migration
Single-prod environments
C-level stakeholder
ClientEuropean’s largest digital real estate tech co.
HQBerlin, Germany
Scope3 European data centers → AWS
Duration~1.5 years (2023–2024)
My rolesLead Architect (team) + Architecture Board
OutcomeFull migration delivered, DC decommissioned
3
European data centers exited
~1.5 yrs
delivery timeline
2× roles
team lead + architecture board
#1
most effective team in the program
Zero
production outages during migration
Delivered as Senior Infrastructure Architect (Manager) at Endava · Highest technical grade in Endava Poland · Cloud Champion
Lead of AWS Cloud Center Poland · LatAm Infrastructure Practice mentor
The Real Challenge
The infrastructure was undocumented
Years of staff turnover had erased institutional knowledge. Documentation was incomplete. Application ownership was unclear. Critical dependencies existed only in the heads of people who had already left. Before migration could begin, the team had to rebuild a map of a complex enterprise environment from scratch.
Failure to migrate on time wasn’t an option
The data centers were approaching operational risk. A real possibility of partial or full infrastructure failure existed if migration was delayed. With some applications running only in production – no staging, no fallback – every migration decision carried direct business risk. There was no room for long analysis cycles or experimentation.
Scale and parallel complexity
This was one of the largest and most complex cloud migration initiatives delivered within Endava. Multiple parallel teams were formed to migrate logical application groups independently, all operating within the same technical and timeline constraints. Coordinating across teams while maintaining architecture consistency, managing dependencies between groups, and staying aligned with C-level business priorities simultaneously – was the structural challenge of the entire programme.
What I Did
A
Team Lead – Cloud migration execution
Led one of the parallel migration teams with direct responsibility for technical planning and execution of the most complex application group migrations. This covered the full migration lifecycle per application: discovery and dependency mapping, migration strategy selection (the right R from the 6 Rs — rehost, replatform, refactor, retire, etc.), detailed migration planning, test catalog preparation, risk assessment, rollback planning, and execution. For applications with only a single production environment, rollback plans had to be rigorous – Cloud migration failure meant production failure. My team became the most effective in the programme, rated highest for both delivery speed and depth of environment understanding.
B
Architecture Board member – enterprise-level decisions
Simultaneously served as a member of the central Architecture team, working on target architecture decisions, migration patterns, and cross-team consistency. In this role I worked directly with the client’s and Endava’s C-level management – translating architectural choices into business terms, reporting programme progress, escalating and resolving risks at the enterprise level. This included ensuring that individual team migrations did not create enterprise-level dependency conflicts or drift from the agreed target architecture.
C
Discovery and environment reconstruction
Before any migration wave could execute, the environment had to be understood. The initial assessment phase involved systematic analysis of the full infrastructure and application landscape: identifying logical application groups, mapping dependencies (including hidden and undocumented ones), and clarifying ownership – both current and post-migration. This was not a one-time exercise. Discovery continued throughout the programme, as migration of one group often revealed dependencies into groups not yet assessed. Building a reliable picture under time pressure, with incomplete source material, is one of the hardest skills in enterprise migration.
What This Engagement Demonstrates
🗺️
Migrating infrastructure you’ve never seen, and that the client hasn’t fully seen either
The hardest migrations are not technically complex ones – they are ones where the source environment is unknown. Starting without documentation, with fragmented ownership and lost knowledge, and building enough clarity to plan and execute migration waves safely is a distinct operational skill. Most consultants arrive when the assessment is done. I was there to do the assessment.
⚡
Operating at two levels of the programme simultaneously
Being both a team-level delivery lead and an architecture board member in the same programme creates a rare perspective. At team level I understood the ground reality of every application we touched. At board level I could see conflicts and risks that team-level views don’t reveal. This dual visibility is what made it possible to resolve cross-team dependency issues before they became programme blockers.
🔒
Migrating single-production applications without a safety net
Some applications had only one production environment. No staging. No fallback unless you built one. For these, migration planning had to be bulletproof: detailed rollback procedures, precise execution windows, pre-tested recovery steps. A failed migration meant a production incident. This forces a quality of planning rigour that lower-stakes migrations do not, and it is exactly the kind of environment that exposes whether a migration lead actually understands what they’re doing.
📐
Architecture governance across parallel teams under time pressure
When multiple teams migrate in parallel, the risk is not individual team failure – it is architectural drift. Teams make locally rational decisions that create cross-programme conflicts: incorrect dependency sequencing, inconsistent naming and account structures, incompatible network designs. Maintaining architecture consistency across a parallel programme while teams are executing under deadline pressure requires both technical authority and trust. Both had to be earned through the quality of the architecture decisions, not through hierarchy.
💼
Translating technical complexity for C-level stakeholders under programme pressure
Enterprise migrations are not purely technical events. Cost projections, risk escalation, timeline re-planning, and architectural trade-off decisions all need to be communicated to senior leadership in business terms. As part of the Architecture Board I was in regular direct contact with the client’s C-level. This meant being able to articulate technical risk in financial and operational impact language, and being trusted to do so accurately under pressure.
Cloud Migration Leadership Skills
Discovery in unknown environments
Rebuilt infrastructure knowledge from fragmented sources with no documentation baseline. Identified logical application groups, mapped hidden dependencies, and clarified ownership under time pressure. The skill most enterprise migrations assume away.
Large-scale AWS migration execution
End-to-end migration of enterprise workloads to AWS across 1.5 years. Assessment, strategy (6 Rs per application), migration planning, test catalogs, execution and hypercare. One of the largest programmes in Endava.
Dual team + board leadership
Simultaneous delivery lead (team execution) and Architecture Board member (enterprise decisions). Ground-level technical depth with programme-level strategic perspective – rare in a single person on a programme.
Rollback and risk management – single production
Planned and executed migrations for applications with no staging environment. Detailed rollback procedures, precise execution windows, pre-tested recovery paths. Zero production outages across the programme.
C-level technical communication
Regular direct reporting to client’s C-level leadership. Translated architecture decisions, risks, and trade-offs into business language. Built and maintained trust with executive stakeholders throughout a complex multi-team programme.
Architecture governance across parallel teams
Maintained consistency across multiple migration teams executing simultaneously – preventing dependency conflicts, architectural drift, and inconsistent AWS account and network structures that create long-term operational debt.
Cost efficiency and cloud economics
Responsible for cost-efficiency and resource optimisation throughout. Evaluated and right-sized resources continuously. Cloud spend optimisation is one of the top failure modes of enterprise migrations – 28% average waste reported by Flexera, and requires active management, not post-migration cleanup.
AWS Cloud expertise (certified)
AWS Solutions Architect certified. Led the AWS Cloud Center in Endava Poland. Contributed to Endava’s Centre of Excellence in Cloud Migration. Highest technical grade in Endava Poland. Cloud Champion designation.
The Core Insight from This Project
The biggest risk in enterprise cloud migration is not technical – it is epistemic.
You cannot migrate what you don’t understand. And 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.
The discovery phase is not a preamble to the migration. It is the migration’s most critical work.
Every dependency mapping failure in the assessment becomes a production incident during execution.
Every application whose ownership was not clarified becomes an escalation that stalls a migration wave.
The second insight: assessment-driven planning is not just risk reduction – it is the only way to run parallel teams effectively.
Without a shared, verified map of the environment, parallel teams create conflicts that compound
faster than any single team can resolve them.
Who This Is Relevant For
You’re migrating but don’t fully know what you have
Staff turnover, legacy acquisitions, inherited infrastructure, missing documentation – this is the normal condition for large organisations, not the exception. The question is whether your migration approach starts with honest discovery or assumes a level of knowledge that doesn’t exist.
You’re running multiple parallel migration teams
Parallel execution is the only way to meet enterprise timelines. But parallel teams need consistent architecture governance, shared dependency visibility, and someone who can see across team boundaries. Without this, the speed of parallel execution creates architectural technical debt faster than any single team could generate it.
You have a deadline you cannot move
Data center lease expiry, operational risk, regulatory requirement – whatever the driver, the deadline is fixed. This changes the character of the migration entirely. The planning must be tighter, the sequencing must prioritise risk, and the rollback planning must be thorough enough that execution can proceed with confidence under pressure.
You need both strategic and hands-on technical leadership
Many programmes have architects who design but don’t execute, and engineers who execute but don’t design. The gap between those two creates friction and rework. Someone who can do both, and translate between the architecture board and the delivery team, is a different kind of contribution.
Your cloud costs are growing faster than expected
Most enterprise migrations overspend in the cloud – Flexera reports 28% average waste. This happens when cost optimisation is treated as post-migration cleanup rather than an embedded practice throughout execution. The discipline of right-sizing and resource governance needs to be built into the migration pattern, not added later.
Your CIO or board needs technical progress in business language
Enterprise cloud programmes live or die on executive trust. When the architecture board and the C-level are not aligned on risk, trade-offs, and timeline, programmes slow down or get cancelled. Bridging that communication gap – accurately, consistently, under pressure — is as important as the technical work itself.
Planning or running a complex cloud migration programme?
In 30 minutes I can tell you whether your situation maps to what I do, and if it does, what engagement makes sense: assessment, architecture, programme lead, or a specific technical challenge you’re stuck on.
No pitch. A direct conversation about your migration, its constraints, and where the real risk lives.