Cloud & DevOps
Cloud migration: move your applications to AWS, GCP, Azure or OVHcloud
Cloud migration means moving applications, databases and infrastructure hosted on physical servers, VPS or a private data centre to a public cloud provider: AWS, Google Cloud, Microsoft Azure or OVHcloud. It can be limited to copying machines as they are (lift-and-shift) or go as far as re-architecting around managed services.
This service is for businesses and software publishers looking for elasticity, resilience or automation, a lighter operational burden, or compliance with data residency requirements. It applies equally to a single line-of-business application and to a fleet of dozens of servers.
We start with an inventory and assessment of each component to choose the right strategy, then build the target with infrastructure as code, migrate data with a cutover plan that minimises downtime, and optimise costs once real workload has been observed.
When do we step in?
Data centre or server contract ending
The lease on your server room or dedicated machines is expiring and renewing the hardware is not justified. The cloud lets you pay only for the capacity you actually use.
Application that can no longer handle the load
Seasonal traffic peaks or user growth are saturating the current infrastructure. Cloud autoscaling and managed services absorb these variations without permanent over-provisioning.
Operations consuming too much time
Your team spends its days applying patches, managing backups and replacing disks. Managed services (databases, message queues, object storage) remove a large share of these tasks.
Resilience and disaster recovery requirements
An incident at a single site would halt the business. The cloud makes multi-zone replication, automated backups and testable recovery plans accessible.
Data residency and compliance
You must host data in a specific region or with a European provider. Choosing the region and provider (for example OVHcloud or a European AWS region) is part of the analysis.
How we work
- 1
Inventory and assessment
Mapping applications, dependencies, network flows, data volumes and availability requirements. Each component is assigned a strategy: rehost as is, replatform onto a managed service, refactor, or retire.
- 2
Provider selection and target design
Comparing offerings against your constraints (region, managed services, costs, in-house skills), then designing the target architecture: networking, accounts and environments, IAM, security, backups and monitoring.
- 3
Building with infrastructure as code
The target is described with Terraform or CloudFormation, so it can be recreated identically, reviewed, and evolved without manual drift.
- 4
Data migration
Databases are migrated with replication tools (AWS DMS, native PostgreSQL or MySQL replication) to reduce the downtime window; files with rsync or bulk transfer tools to object storage.
- 5
Progressive cutover
We favour cutting over application by application or by traffic percentage, with rollback possible as long as the old environment stays in sync. DNS and TTLs are prepared in advance.
- 6
Optimisation and knowledge transfer
After a few weeks of observation, we adjust sizing, set up reserved instances or commitment plans, and train your teams to operate the new platform.
Technologies we use
- AWS (EC2, RDS, S3, ECS)
- Google Cloud
- Microsoft Azure
- OVHcloud
- Terraform
- AWS DMS
- Docker
- Kubernetes
- PostgreSQL and MySQL
- Cloudflare and Route 53
- Prometheus and Grafana
Why choose Agencei?
Strategy chosen component by component
Migrating everything as lift-and-shift reproduces existing problems; re-architecting everything is expensive and slow. We apply the right strategy to each application based on its value and lifespan.
Infrastructure as code from the start
No resource is created by hand in a console. The target is versioned, reviewed and reproducible, which simplifies test environments and audits.
Cloud cost control
The cloud can cost more than a dedicated server if poorly sized. We instrument costs from day one and adjust after observing the real workload.
Reversible cutover
Until the migration is validated, the old environment stays in sync and rollback is planned, tested and documented.
In brief
- What is this service?
- Cloud migration is the transfer of applications, data and infrastructure from physical servers or VPS to a public cloud provider such as AWS, Google Cloud, Azure or OVHcloud, either as lift-and-shift or with re-architecture.
- Who is it for?
- Businesses and software publishers seeking elasticity, resilience, automation or data residency compliance, and wanting to reduce their operational burden.
- What problem does it solve?
- Leaving ageing or saturated infrastructure without business interruption, without runaway costs and without reproducing existing weaknesses.
- How long does it usually take?
- Typically a few weeks for an application rehosted as is, several months for a fleet of applications migrated in waves with partial re-architecture.
- What factors influence the price?
- The number of applications and their dependencies, data volume, the share of re-architecture, availability requirements during cutover and the level of knowledge transfer desired.
- How does the engagement run?
- Inventory and assessment, provider selection and target design, infrastructure as code build, data migration by replication, progressive cutover, then cost optimisation.
- What are the risks?
- Unidentified dependencies, underestimated costs, latency between components left on-premises and migrated ones, overly broad IAM permissions, and no rollback plan.
- What alternatives exist?
- Staying on modernised dedicated servers, adopting a private cloud or managed hosting, or migrating only certain components (storage, backups, database) in a hybrid approach.
Frequently asked questions
Lift-and-shift or re-architecture: which should I choose?
Lift-and-shift copies your machines as they are: fast, low risk, but without the benefits of managed services. Re-architecture adapts the application to the cloud (containers, managed databases, functions): longer, but it reduces operations and costs over time. The right choice is made application by application.
How long does a cloud migration take?
A simple application rehosted as is can be migrated in a few weeks. A fleet of several applications with partial re-architecture usually spans several months, in successive waves.
Is the cloud always cheaper?
No. At constant capacity and without optimisation, public cloud is often more expensive than a dedicated server. Savings come from elasticity, reduced operations time, and sizing adjusted after observation. We give you an estimate before starting.
Which provider do you recommend?
It depends on your constraints. AWS has the broadest catalogue, Google Cloud is strong on data and Kubernetes, Azure integrates with the Microsoft ecosystem, OVHcloud meets European hosting requirements. We compare against your real criteria rather than a preference.
How do you limit downtime when migrating databases?
By setting up continuous replication between the old and new database, then switching once replication lag is zero. The downtime window is then limited to the time it takes to restart the applications.
Related services
AWS Services
Design, deployment and optimisation of AWS infrastructure: compute, databases, storage, IAM, costs.
See this serviceServer Migration
Full transfer of a dedicated server or VPS to a new machine, with OS upgrade and a controlled cutover.
See this serviceDevOps Consulting
Setting up CI/CD, infrastructure as code, monitoring and GitOps practices.
See this serviceKubernetes Consulting
Kubernetes clusters (EKS, k3s), Helm charts, ingress, autoscaling and observability for your applications.
See this serviceData migration
Migration between databases, engines, versions or systems, with ETL, validation and zero-downtime cutover.
See this serviceTell us about your project
Describe your need in a few lines: we come back to you with a first analysis and the next steps.