Undocumented dependencies
Applications talk to databases, file shares, mail servers and third-party APIs in ways nobody wrote down until something breaks.
Cloud & DevOps · Migration
Cloud migration services with a rehearsed cut-over and a way back
We move one system at a time, practice every migration before the real one, and keep the old environment ready until the new one has proven itself.
What is Cloud Migration?
Cloud migration services move an organization's applications, databases and files from on-premises servers, shared hosting or another provider onto a cloud platform. Each workload is assigned a strategy (rehost it as it is, replatform it onto managed services, refactor it, replace it or retire it) and then migrated through rehearsals, a planned cut-over and a defined rollback path. The aim is a move that users barely notice, apart from, ideally, better performance.
Migrations go wrong when they are treated as copying files. Hidden dependencies surface on the night: a hard-coded IP address, a licence tied to a machine, a scheduled job no one documented, an email relay that only accepts the old server. Without a rehearsal and a rollback plan, a weekend cut-over turns into days of firefighting while the business waits.
Where cloud migrations usually break
Downtime the business can't absorb
An online store, ERP or patient system cannot simply be switched off for a long migration window.
Large or changing data
Databases that are big or written to constantly need replication or incremental sync, not a single export and import.
Moving the problems along with the servers
Lifting an oversized, unpatched server into the cloud as-is can cost more than before while keeping every old weakness.
Our Cloud Migration service
Discovery and dependency mapping
An inventory of servers, applications, databases, DNS records, certificates, scheduled jobs and integrations, with the connections between them drawn out.
Strategy per workload
Each system classified as rehost, replatform, refactor, replace or retire, with the reasoning and effort written down.
Target environment build
The destination network, compute, databases and access set up, ideally with infrastructure as code, following an agreed cloud architecture.
Data migration and sync
Database dumps, replication or incremental sync and file transfer chosen to suit data size and acceptable downtime, with row counts and checksums verified.
Rehearsal and cut-over
At least one full trial migration, then a written cut-over runbook covering DNS changes, freeze windows, verification and who decides go or no-go.
Rollback and decommissioning
A tested way back if verification fails, and only after a stable period, the controlled shutdown of the old environment.
Included capabilities
- Server and application inventory
- Dependency maps per application
- Migration wave planning
- DNS TTL lowering ahead of cut-over
- Database replication or incremental sync
- Data verification with counts and checksums
- Cut-over runbook with go/no-go criteria
- Rollback plan rehearsed before go-live
- Post-migration monitoring and tuning
What Cloud Migration changes for your business
Lower migration risk
Rehearsals and rollback plans turn the cut-over into a repeat of something already done once.
Shorter downtime
Replication and pre-staged data reduce the final window to the minimum each system allows.
A cleaner destination
Retiring unused systems and right-sizing the rest avoids paying cloud prices for old waste.
A documented estate
The discovery work leaves you with an inventory and dependency map you probably never had.
Where it makes the biggest difference
Office server to cloud
An ERP, accounting or file server sitting in an office cupboard moved to a cloud environment with proper backups and remote access.
Shared hosting to VPS or cloud
A business website or web application that has outgrown shared hosting moved to an environment it can control and scale.
Provider to provider
Workloads moved between hyperscalers and simpler providers in either direction, for cost, region or support reasons.
Migration with modernization
A legacy application replatformed onto containers and a managed database during the move, instead of copied unchanged.
Eight steps from inventory to decommission
The real cut-over is never the first time a migration has been run.
Discover
Inventory systems, measure their resource use and map every dependency we can find.
Decide strategy
Assign a migration strategy to each workload and group them into waves, starting with lower-risk systems.
Prepare the target
Build the destination environment, access controls, monitoring and backups before any data moves.
Rehearse
Run a full trial migration, test the application on the new platform and time each step.
Plan cut-over
Agree the window, the freeze, the runbook, the verification checks and the rollback trigger.
Cut over
Final sync, DNS switch and verification, with the old environment kept ready.
Stabilize
Monitor closely, fix issues, right-size resources once real usage is visible.
Decommission
Retire the old environment after an agreed stable period and a final backup.
What it connects to
Cloud Migration
- AWS, Google Cloud and Azure
- DigitalOcean, Hetzner and Hostinger VPS
- On-premises Windows and Linux servers
- cPanel and shared hosting accounts
- PostgreSQL, MySQL and MongoDB
- DNS providers and Cloudflare
- Email and SMTP relays
- Object storage and file shares
Built with
Cloud migration strategies compared
| Criterion | Rehost (lift and shift) | Replatform | Refactor |
|---|---|---|---|
| What changes | Nothing in the application; servers move as they are | Some components swapped for managed services, e.g. database | Application redesigned to be cloud-native |
| Effort | Lowest | Moderate | Highest |
| Speed to migrate | Fastest | Moderate | Slowest |
| Cloud benefits gained | Few; mainly leaving old hardware | Managed backups, scaling of selected parts | Most: scaling, resilience, automation |
| Best fit | Deadlines, stable legacy apps | Most business applications | Core products with a long future |
Security, quality and scale
Encrypted transfer
Data moves over encrypted channels and is never left in temporary public locations.
Access reset
Old shared passwords and keys are not carried over; access is rebuilt with named accounts and least privilege.
Backups before every step
Verified backups of source systems are taken before the rehearsal and before the final cut-over.
Capacity check
The target is load-tested against observed peak usage so the new platform is not undersized on day one.
What working with us looks like
Rollback is planned, not improvised
Every cut-over we run has a defined trigger and procedure for returning to the old system.
Application knowledge
Because we develop software, we can fix the hard-coded paths and config issues that typically stall a migration.
Experience with business systems
We migrate ERP, Odoo, WordPress and custom applications, not just generic servers.
Honest strategy calls
If a system should be retired or replaced rather than migrated, we say so before you pay to move it.
What it costs
Fixed-price packages with the scope written down, paid stage by stage. Your project goes live once it's fully paid.
Related services, technologies and industries
Sources and further reading
Official documentation and guidance if you want to read more about this topic.
Cloud Migration: questions we hear most
How much downtime does a cloud migration involve?
Downtime depends on data size, how often data changes and whether replication is possible for that system. Some workloads can cut over in a short maintenance window using replication; others need a longer planned freeze. We measure this during the rehearsal and agree the window with you before the real migration.
What is the difference between rehosting and replatforming?
Rehosting moves a system to the cloud unchanged, while replatforming changes some components on the way, such as moving a self-hosted database to a managed one. Rehosting is quicker; replatforming takes a little longer but usually removes operational work and cost afterwards.
What happens if something goes wrong during cut-over?
We follow the rollback plan agreed in advance: the old environment stays intact and DNS or traffic is pointed back to it. Because the go/no-go criteria are written down, the decision to roll back is quick rather than debated in the middle of the night.
Will our cloud costs be lower after migrating?
Not automatically. Cloud costs depend on how resources are sized and used, and a lift-and-shift of oversized servers can cost more than before. We right-size during and after migration and show you the expected running cost before you commit.
Can you migrate Odoo or WordPress to the cloud?
Yes. We regularly move Odoo databases and filestores, WordPress sites and custom web applications between hosts and providers. Odoo version upgrades are a separate service from moving where Odoo runs, and we keep the two distinct in the plan.
Next step
Map your migration before you move
List the systems you want to move and where they run today. We'll outline a strategy per workload and the questions the rehearsal must answer.