After successfully exiting three European data centers to AWS, the same programme team took on the next challenge: migrating the entire French enterprise infrastructure – the French subsidiary – from Orange Cloud to AWS. Orange Cloud is a proprietary French telecom-operator cloud used almost exclusively by French enterprises. Nobody on the team had worked with it before. Neither had most of the migration tooling we relied on. We completed the migration in six months.
Unknown proprietary cloud
Cloud-to-cloud migration
French enterprise
C-level stakeholder
6-month delivery
Architecture board
Cloud-to-cloud migration
French enterprise
C-level stakeholder
6-month delivery
Architecture board
ClientEuropean’s largest digital real estate tech co.
SourceOrange Cloud (proprietary French cloud)
TargetAWS
Duration~6 months (2024)
My rolesLead Architect (team) + Architecture Board
OutcomeFull migration delivered on schedule
0
prior team experience with Orange Cloud
6 months
full enterprise migration delivered
Phase 2
of programme after 3-DC migration
French
C-level direct stakeholder management
Zero
production incidents during migration
Sequel to the 3-data-center AWS 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
What Made This Different
Cloud-to-cloud migration is not simply a variation of data center migration. When the source is a proprietary platform built and operated by a French telecoms company, the challenges are categorically different, and none of the standard migration tooling, community knowledge, or prior patterns directly apply.
Orange Cloud: a platform nobody outside France knows
Orange Cloud is a French telecom-operator cloud platform used almost exclusively by French enterprises on specific commercial and compliance arrangements with Orange. There is no significant community around it. Migration tooling designed for AWS, Azure, or GCP does not support it. English documentation is scarce. There is no established playbook for migrating off it to any other cloud.
Cloud-to-cloud is a different migration class
On-premise migrations can be approached with well-established tooling and patterns. Cloud-to-cloud from a proprietary platform means dealing with provider-specific networking topologies, identity and access models, storage APIs, and billing structures that have no direct AWS equivalent. Each service dependency had to be understood from first principles, not mapped from a known pattern.
Lost institutional knowledge – again, but in a different way
As with the 3-DC migration, staff turnover had eroded internal knowledge of the environment. But here the challenge was compounded: even where documentation existed, it described Orange Cloud concepts and configurations that our team had never encountered. Understanding what was written required simultaneously learning the platform and mapping the environment.
French subsidiary, French C-level, French context
French company operated with its own C-level leadership and its own organisational priorities within the larger group. Stakeholder management required direct engagement with French executives – understanding their specific business context, regulatory considerations, and priorities, and communicating technical decisions and risks in terms that resonated with their operational reality.
What I Did
1
Learn Orange Cloud from zero – while assessing the environment
Before any migration planning could begin, the team had to develop sufficient understanding of Orange Cloud’s architecture model, networking primitives, storage services, and identity systems – with no prior experience and limited documentation. This was not a research exercise done separately from the project: it happened in parallel with the discovery and assessment phase. Understanding the platform was the prerequisite for understanding the environment that ran on it.
2
Apply proven discovery and assessment patterns – adapted for cloud-to-cloud
The structured assessment methodology from the 3-DC programme – identifying logical application groups, mapping dependencies, clarifying ownership – was applied directly here. The adaptation was in how cloud-specific dependencies were identified and mapped: Orange Cloud networking configurations, storage mounts, IAM dependencies, and managed services all required translation into their AWS equivalents rather than straight replication. The speed advantage came from not having to design the methodology from scratch.
3
Lead migration execution and maintain architecture consistency
As team lead, I was responsible for planning and executing migrations within the agreed architecture and timeline – applying the same migration rigour as in the 3-DC programme. As Architecture Board member, I worked on defining migration patterns specific to this cloud-to-cloud context, resolving architectural questions that had no established precedent, and ensuring cross-team consistency across parallel migration waves.
4
Direct C-level communication with French subsidiary leadership
French C-level management had their own business priorities, risk tolerance, and communication expectations – distinct from the parent group. Regular direct reporting, risk escalation, and technical-to-business translation had to be calibrated for this specific executive audience. This included understanding French enterprise culture, the commercial relationship with Orange, and the local operational implications of migration timing and sequencing decisions.
What This Engagement Demonstrates
🔍
Navigating a proprietary cloud with no community, no tooling, and no playbook
Most cloud migration knowledge is built around the major hyperscalers. When the source platform is proprietary and French-operator-specific, that knowledge base does not apply. Building the mental model of Orange Cloud – its networking topology, storage abstractions, IAM model, and managed services – from first principles, under project timelines, and then translating that into AWS migration patterns is a qualitatively harder problem than migrating from documented on-premise infrastructure.
⚡
6 months: what methodology maturity looks like at speed
The 3-DC programme took 1.5 years. This one – comparable enterprise scope, harder source platform – was completed in six months. The speed was not a function of the problem being simpler. It was a function of an already-calibrated team, a proven methodology applied without friction, and architecture patterns that had been battle-tested in the previous programme. This is what reusable migration capability looks like in practice.
🇫🇷
Cross-cultural enterprise stakeholder management
Working directly with French C-level executives requires more than translation of technical concepts into business language – it requires understanding the cultural and organisational context in which those executives operate. French enterprise culture has specific expectations around how decisions are escalated, how risk is communicated, and how a programme team earns credibility with leadership. Getting this right – in a subsidiary context, under delivery pressure – is a distinct leadership skill.
📐
Cloud-to-cloud architecture: building patterns where none existed
Cloud-to-cloud migration from a proprietary source requires creating migration patterns from scratch. Orange Cloud networking configurations do not map cleanly to AWS VPC constructs. Storage APIs differ. IAM models differ. The architecture board work here was not applying known patterns – it was designing new ones, validating them against the source platform’s behaviour, and establishing a pattern library for the team to execute against. This is architecture work at its most demanding.
Skills This Project Evidences
Proprietary cloud platform mastery under pressure
Learned and assessed Orange Cloud – a French-operator proprietary platform with no community or standard tooling support – from zero, within project timelines, while simultaneously mapping and planning migration of the environment hosted on it.
Cloud-to-cloud migration architecture
Designed and applied migration patterns for cloud-to-cloud transitions from a proprietary source, including networking translation, storage abstraction mapping, IAM model conversion, and managed service equivalence, where no established playbook existed.
High-velocity enterprise delivery
Delivered a full enterprise infrastructure migration in 6 months despite zero prior platform experience. Speed was achieved through methodology reuse and team calibration from the preceding 3-DC programme – demonstrating what repeatable migration capability looks like at scale.
Cross-cultural C-level stakeholder management
Managed direct relationships with French C-level executives -navigating different cultural expectations, communication styles, and organisational priorities from the parent group. Built and maintained executive trust throughout a high-stakes delivery.
Dual programme role (team + board)
Same dual-role structure as the 3-DC programme: team-level delivery lead and Architecture Board member simultaneously. Ground-level execution detail combined with enterprise-level pattern design and consistency governance.
Discovery without a reference framework
Unlike on-premise or hyperscaler environments, Orange Cloud had no standard conceptual reference to apply. Discovery required building the conceptual framework from scratch, then using it to map the environment – a double-discovery challenge with no shortcuts.
Methodology transfer and team performance
Successfully transferred assessment, planning, and execution methodology from a preceding programme to a new context with a harder source platform. My team was again among the most effective in the programme on both delivery speed and environment understanding.
Operational continuity under unknown platform risk
Migrating from a platform whose failure modes are not well understood adds a risk dimension absent from on-premise migrations. Planning for the unexpected – when the unexpected could be anything – requires more conservative rollback preparation and more disciplined execution windows. Zero production incidents.
Programme Context – How This Fits the Bigger Picture
This project was the second major chapter of a multi-year cloud migration programme for one of the world’s largest digital real estate tech companies. The first chapter – migrating 3 European data centers to AWS over 1.5 years – established the team, the methodology, and the architecture patterns.
French company was a different company, a different cloud platform, a different country, and a different executive audience. But the core challenge was the same: migrate a complex enterprise environment you don’t fully understand, under time and operational pressure, without production incidents.
The insight across both projects: migration methodology is an asset that compounds. The patterns, the team calibration, the risk frameworks, and the architectural decisions from the first programme directly enabled the speed of the second — even when the source environment was categorically more unfamiliar.
Who This Is Relevant For
You’re migrating from a proprietary or legacy cloud platform
Not every company runs on AWS, Azure, or GCP. VMware Cloud, telco-operator clouds, national government clouds, legacy private clouds – each has its own migration challenge. The skills required to navigate an unfamiliar proprietary source platform are fundamentally different from standard hyperscaler migration experience.
You need speed, not just safety
6 months for a full enterprise migration from an unknown cloud platform is fast. That speed came from a mature methodology, not from cutting corners on risk. If your programme needs to accelerate without increasing operational risk, the answer is better methodology, not more people.
You operate across multiple countries or subsidiaries
Subsidiaries have their own leadership, their own priorities, and their own organisational culture. Managing a migration that is simultaneously a group programme and a local subsidiary initiative requires navigating both layers simultaneously – understanding which decisions are made at group level and which need to be negotiated locally.
You’re exiting a vendor relationship, not just migrating workloads
Orange Cloud was a commercial and operational dependency – a telecom-operator relationship with specific contractual and compliance dimensions. Exiting it required understanding not just the technical migration but the commercial context in which the platform was being used and the operational implications of the transition.
You want to build reusable migration capability, not just execute a one-off
The speed of this project was a direct product of the investment made in methodology during the previous programme. Organisations that treat each migration as a one-off project miss the opportunity to build a capability that compounds. The patterns, tooling, and team calibration from one programme are the assets that make the next one faster and safer.
Your CTO or CIO needs a migration lead, not just a migration team
A team can execute. A lead makes the architectural and risk decisions that determine whether execution goes well. The difference is especially visible when the environment is unfamiliar, the platform is proprietary, and the stakeholder relationships need to be managed across cultural and organisational lines simultaneously.
Migrating from a proprietary, legacy, or unfamiliar cloud platform?
In 30 minutes I can tell you whether your situation maps to what I do – what the real risks are in your specific migration context, and what a structured approach would look like for your environment.
No pitch. A direct conversation about your cloud, your constraints, and where the real complexity lives.