Migrating a French Enterprise From a Cloud Nobody Uses: Orange Cloud to AWS in 6 Months

The challenge

Orange Cloud is the cloud platform of the French telecom operator Orange, used almost exclusively by French enterprises on specific commercial and compliance arrangements with Orange. There is no significant community around it, English documentation is scarce, and there was no established playbook for migrating off it to any other cloud.

Standard migration tooling is built for the big platforms. AWS Application Migration Service, for example, lists physical servers, VMware, Hyper-V, Azure and Google Cloud as sources, and Orange Cloud is not one of them. Its networking, identity and access model, storage APIs and billing had no direct AWS equivalent, so each service dependency had to be understood from first principles.

Staff turnover had also eroded internal knowledge of the environment. Even where documentation existed, it described Orange Cloud concepts and configurations the team had never seen, so we had to learn the platform and map the environment at the same time.

The French subsidiary had its own C-level leadership and its own priorities within the larger group. Technical decisions and risks had to make sense to these executives in terms of their own business, regulatory and operational context.

My task: lead my team through planning and executing the migrations, and as an Architecture Board member, define the migration patterns for this cloud-to-cloud move and keep the architecture consistent across parallel waves.

What makes a cloud-to-cloud migration different?

In a data center migration you move servers you control, and well-known tools and patterns exist for it. In a cloud-to-cloud migration the source is another provider’s platform. Its networking topology, identity and access model, storage APIs and managed services follow their own logic, often with no direct AWS equivalent. Each service dependency has to be understood first and then translated into the matching AWS services. When the source is a smaller, regional cloud, there is also less documentation, less community knowledge and less tool support to lean on, and the provider’s failure modes are harder to predict.

What I did

1. Learned Orange Cloud from zero while assessing the environment

   Before any migration planning, the team had to understand Orange Cloud’s architecture model, networking, storage services and identity system, with no prior experience and limited documentation. This happened in parallel with discovery and assessment: understanding the platform was the only way to understand the environment that ran on it.

2. Applied proven discovery and dependency mapping to a cloud-to-cloud move

   We applied the assessment method from the 3-data-center programme directly: identify logical application groups, map dependencies and clarify ownership. The adaptation was in the cloud-specific dependencies. Orange Cloud networking configurations, storage mounts, IAM dependencies and managed services were translated into their AWS equivalents rather than replicated. Not having to design the method from scratch gave us the speed.

   Technical details

   • Discovery output: logical application groups, a dependency map and a clear owner for every application.
   • Translation to AWS: networking configurations to AWS VPC constructs, storage mounts and storage APIs to AWS storage services, the IAM model to AWS IAM, and managed services to their AWS equivalents.

3. Led the migration waves and set the cloud-to-cloud patterns

   As team lead, I planned and executed migrations within the agreed architecture and timeline, with the same rigour as in the 3-data-center programme. As an Architecture Board member, I defined migration patterns for this cloud-to-cloud context, resolved architecture questions that had no precedent and kept the parallel migration waves consistent across teams. The patterns were validated against the source platform’s behaviour and collected into a pattern library for the teams to work from.

   Technical details

   • Risk control: Orange Cloud’s failure modes were not well understood, so rollback preparation was more conservative and execution windows more disciplined than in an on-premise migration.
   • Architecture Board: the cross-team group that defined migration patterns and kept architecture decisions consistent across the programme.

4. Reported directly to the French C-level management

   The French leadership had its own priorities, risk tolerance and communication expectations, different from the parent group. I kept regular direct reporting and risk escalation with them, and translated technical decisions into business terms for this audience. That included the commercial relationship with Orange and the local impact of migration timing and sequencing.

Results

The migration was delivered on schedule:

• The French subsidiary’s entire infrastructure moved from Orange Cloud to AWS in about six months.
• Zero production incidents during the migration.
• A pattern library for cloud-to-cloud moves, validated against the source platform’s behaviour.
• Consistent architecture across parallel migration waves, governed through the Architecture Board.
• My team was again among the most effective in the programme, in delivery speed and in understanding the environment.
• The method from the 3-data-center programme, which took 1.5 years, reused for a comparable scope in six months.

What I learned

Migration methodology is an asset that compounds.

The patterns, the team calibration, the risk frameworks and the architecture decisions from the first programme made the second one fast, even though its source platform was much less familiar. The speed came from an already-calibrated team and a proven method applied without friction; the problem itself was harder. Treating each migration as a one-off project throws that advantage away.

Evidence and further reading

• Related projectMigrating 3 European data centers to AWSThe first chapter of the programme: the team, the method and the architecture patterns.
• Service · this siteCloud migration consultingHow I plan and lead migrations to the cloud.
• Service · this siteCloud exit consultingWhen a migration is also an exit from a cloud provider.

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 and mentored the LatAm infrastructure practice.

Skills and technologies

• Cloud-to-cloud migration
• AWS migration
• Orange Cloud
• Discovery and assessment
• Dependency mapping
• Migration waves
• Migration patterns
• Architecture Board
• AWS VPC networking
• AWS IAM
• Rollback planning
• Risk management
• C-level stakeholder management
• Cross-cultural leadership
• Team leadership
• Vendor exit

← All projects