Cloud migration services move your websites, applications and databases from wherever they live today – a shared hosting account, an ageing in-house server, an overpriced hyperscaler setup – to cloud infrastructure that is faster, easier to operate and priced in a way you can predict. Done well, a migration is invisible to your customers: one day the site simply loads faster and the infrastructure bill is smaller. Done badly, it means lost orders, broken emails and a weekend of firefighting.
Contents
At CodeWiz we plan and execute migrations to Hetzner, DigitalOcean and other providers, with Cloudflare in front as the performance and security layer. We inventory everything your system depends on, choose the right target for each workload, rehearse the cutover, move the data with a rollback path ready, and tune the new environment so you actually get the performance you are paying for.
This service is for companies that have outgrown shared hosting, teams paying hyperscaler prices for workloads that do not need hyperscaler features, and businesses with one critical server nobody wants to touch. Not sure moving makes sense at all? That is what the first assessment answers.
Cloud Migration Assessment: Knowing What You Are Moving
Most failed migrations fail before a single file is copied. Someone forgets the cron job that sends invoices at midnight, the SMTP relay whitelisted by IP, the hard-coded path in a config file, or the third-party API that only accepts requests from the old server’s address. Our first deliverable is therefore an inventory, not a server.
What we map
- Applications and runtimes: PHP, Node.js, Python, web server, background workers and scheduled jobs.
- Data: databases and their sizes, write rates, uploads, sessions and search indexes.
- Network dependencies: DNS records, mail (MX, SPF, DKIM, DMARC), IP whitelists at partners, incoming webhooks.
- Traffic profile: peak hours, visitor locations and monthly bandwidth.
- Requirements: acceptable downtime, recovery targets (RPO and RTO) and data residency.
Choosing a migration strategy per workload
Not everything should be migrated the same way. We decide per workload, using the familiar “R” strategies:
| Strategy | What it means | Effort | When it fits |
|---|---|---|---|
| Rehost (lift and shift) | Same stack on new servers, configuration adjusted | Low | Stable applications, tight deadlines |
| Replatform | Small changes to use managed databases, object storage or containers | Medium | Most web applications – best balance of effort and benefit |
| Refactor | Re-architect parts for the cloud: stateless app tier, queues, autoscaling | High | Systems that have outgrown a single server |
| Retire or replace | Switch off unused components or replace them with SaaS | Varies | Old admin tools and duplicate services |
The output of the assessment is a written migration plan: target architecture, provider and region choice, sequence of moves, cutover method per service, rollback plan and a monthly cost estimate for the new setup compared to the current one.
Hetzner Setup: Serious Performance at a Fraction of the Cost
Hetzner is our default recommendation when price-performance matters most, which is most of the time. Its cloud and dedicated servers offer a lot of CPU, RAM and NVMe storage for the money, generous included traffic and data centres in Germany and Finland, which also simplifies GDPR conversations. The trade-off is fewer managed services than AWS or DigitalOcean, so more of the platform is built and operated by us.
How we build a Hetzner environment
- Cloud or dedicated: shared vCPU cloud servers for web tiers and staging, dedicated vCPU or Arm (CAX) instances for steady workloads, and dedicated root servers for large databases where they are far cheaper than equivalent cloud capacity.
- Private networking and firewalls: databases never get a public port, and only HTTPS from Cloudflare and SSH from known addresses reach the servers.
- Load Balancers and floating IPs for setups that need several application servers or fast failover.
- Volumes, Storage Boxes and Object Storage for persistent data and off-server backups, in addition to snapshots.
Servers are created from code and configured with cloud-init, so every environment is reproducible. A typical bootstrap with the hcloud CLI looks like this:
hcloud network create --name prod-net --ip-range 10.0.0.0/16
hcloud network add-subnet prod-net --network-zone eu-central \
--type cloud --ip-range 10.0.1.0/24
hcloud firewall create --name web --rules-file web-rules.json
hcloud server create --name app-1 --type cpx31 \
--image ubuntu-24.04 --location fsn1 \
--network prod-net --firewall web --ssh-key deploy \
--user-data-from-file cloud-init.yamlThe Hetzner Cloud documentation covers each building block in detail; our job is putting them together into an environment that is secure by default and documented for your team.
DigitalOcean Deployment: Managed Services Without Hyperscaler Complexity
DigitalOcean sits between a raw VPS provider and a hyperscaler. It is a strong choice when you want managed building blocks – databases, Kubernetes, load balancers, object storage – with clear pricing and a dashboard your team can understand, and you do not want to spend days in IAM policies.
What we typically deploy
- Droplets inside a VPC for application servers, with Cloud Firewalls and monitoring agents enabled.
- Managed Databases (PostgreSQL, MySQL, Valkey/Redis) with standby nodes, automatic failover, daily backups and point-in-time recovery – a big operational burden removed.
- DigitalOcean Kubernetes (DOKS) when the application is already containerized and has several services.
- App Platform for simpler apps and APIs where you want git-push deploys without managing servers at all.
- Spaces with its built-in CDN for uploads and static assets, and Load Balancers in front of multiple Droplets.
doctl databases create prod-pg --engine pg --version 17 \
--region fra1 --size db-s-2vcpu-4gb --num-nodes 2Resources go into the region closest to your users – Frankfurt or Amsterdam for European audiences – and the database accepts connections only from trusted sources inside the VPC. For a broader view of how providers compare, see our article on deployment strategies across DigitalOcean, AWS, Hetzner and bare metal.
Hetzner vs DigitalOcean vs AWS: Choosing the Target
There is no universally best cloud. The right target depends on which services you need managed, where your users are and how much operational work you want to own.
| Criterion | Hetzner | DigitalOcean | AWS / hyperscalers |
|---|---|---|---|
| Price-performance | Excellent | Good | Lower for plain compute; you pay for breadth |
| Managed services | Core building blocks (load balancers, volumes, object storage) | Managed databases, Kubernetes, App Platform, Spaces | Hundreds of services for almost any need |
| Traffic costs | Generous included traffic | Bandwidth pool included per Droplet | Egress billed per GB and easy to underestimate |
| Learning curve | Low | Low | High (IAM, networking, billing) |
| Best for | Cost-sensitive production, databases on dedicated hardware, EU data residency | Teams that want managed services with simple operations | Enterprise requirements, specialised services, global multi-region scale |
Mixed setups are common and often ideal: application and database servers on Hetzner, Cloudflare at the edge, and a specific managed service from a hyperscaler only where it earns its price.
Cloudflare Optimization: The Layer That Makes Migrations Safe
Cloudflare does more for a migration than speed up the finished site. When your domain is proxied through Cloudflare, visitors connect to Cloudflare, not to your server, so switching to the new origin is a change of one IP address that takes effect within seconds – no waiting for DNS caches to expire, and an equally fast rollback. That is why moving DNS to Cloudflare is usually our first step, weeks before any server changes.
What we configure
- Origin protection: the new servers accept web traffic only from Cloudflare IP ranges, or not at all from the internet when we use a Cloudflare Tunnel and the origin has no open inbound ports.
- Full (strict) TLS with origin certificates, so traffic is encrypted and verified end to end.
- Cache Rules and Tiered Cache so static assets, and HTML where possible, are served from the edge.
- WAF, rate limiting and bot protection tuned to your application, not left at defaults.
- Load balancing and health checks across origins when you run in more than one location.
We have covered caching, compression and performance settings in depth in our guide to professional Cloudflare configuration; in a migration project, we apply those settings to the new origin and verify cache hit ratios before and after the move.
Zero-Downtime Cutover and Data Migration
The cutover is the moment that matters. Our goal is that customers do not notice it and that no data written during the switch is lost.
How we move data safely
- Databases: small ones get a short maintenance window with a consistent dump and restore. For larger or busy ones, we replicate from the old server to the new one (MySQL replication or PostgreSQL logical replication), let it catch up, then promote the new primary in seconds.
- Files and uploads: an initial bulk copy days in advance, then repeated incremental syncs so the final sync takes minutes, not hours.
- Write freeze: during the final step, the application goes read-only or into maintenance mode briefly, so nothing is written to the old system after the last sync.
- Verification: row counts, checksums and smoke tests of critical paths – login, checkout, contact forms, email delivery – before traffic is switched.
# Days before: bulk copy, repeated until the delta is small
rsync -aHAX --delete --info=progress2 old-server:/var/www/app/ /var/www/app/
# Cutover window: maintenance on, final delta, promote new database
php artisan down
rsync -aHAX --delete old-server:/var/www/app/storage/ /var/www/app/storage/
# then switch the Cloudflare origin and run smoke testsFor online stores the stakes are higher, because every minute of inconsistency can mean a lost or duplicated order. There we also pause payment webhooks or queue them, and reconcile orders from the payment provider’s dashboard after the switch.
Post-Migration Performance Optimization
New hardware does not automatically make an application fast. Default PHP-FPM pools and an untuned database can leave half the new capacity unused, so after migration we tune the environment to the workload it actually runs.
What we tune and measure
- Baseline first: response times, throughput and error rates are measured on the old system before the move, so improvements are proven, not assumed.
- Right-sizing: CPU, RAM and disk are matched to observed usage, not to guesses.
- Runtime and database settings: PHP-FPM workers, OPcache, Node.js process counts and database buffers and connection limits sized for the new machine.
- Latency: the database sits on the same private network as the application – cross-region database calls are a classic hidden slowdown.
- Load testing: realistic scenarios with k6 confirm the new setup handles peaks with headroom.
Keeping Cloud Costs Under Control
Many businesses move to the cloud to save money and end up paying more. The causes are predictable, and we design against them from the start:
- Instances sized for an imagined peak and never revisited.
- Outbound and inter-region traffic billed per GB, invisible until the invoice arrives.
- Forgotten snapshots, volumes and test environments that keep running.
- Managed services used where a simple server would do at a fraction of the price.
We tag resources, set up billing alerts and review usage after the first month. Moving steady workloads off a hyperscaler to Hetzner or DigitalOcean – often called cloud repatriation – can be the single biggest saving. For sites that need a control panel, an open-source hosting panel keeps management simple without licence fees.
Common Cloud Migration Mistakes
- Changing DNS without lowering TTLs first, so part of the traffic hits the old server for hours or days.
- Forgetting email: MX records, SPF entries listing the old server’s IP, or a contact form that relied on the old server’s local mail.
- No rollback plan, or a rollback plan that was never tested.
- Leaving the new database exposed on a public IP “temporarily”.
- Switching off the old server immediately, before backups and a few days of stable operation are confirmed.
What Drives the Cost of a Cloud Migration
We give a fixed scope and estimate after the assessment. The main factors are:
- The number of applications, servers and databases, and how well they are documented.
- Data volume and acceptable downtime – zero-downtime replication takes more preparation than a maintenance window.
- The chosen strategy: rehosting is quicker than replatforming or refactoring.
- Compliance requirements and whether you want ongoing operations after the move.
How We Work
- Assessment: we inventory applications, data, dependencies and traffic, and agree on downtime and recovery targets.
- Plan: we choose the provider, region and strategy for each workload, design the target architecture and write the cutover and rollback runbook.
- Build: we provision the new environment from code, put Cloudflare in front, and set up backups and monitoring before any data moves.
- Rehearse: we run a full test migration, verify data integrity and measure performance against the baseline.
- Cutover: we migrate in a planned window, switch traffic through Cloudflare and watch closely for the first hours and days.
- Optimize and hand over: we right-size, tune, decommission the old infrastructure safely and deliver documentation – or stay on to run it.
Why CodeWiz
- Developers, not just administrators: we build Laravel, Node.js, WordPress and AI applications ourselves, so we know what they need from infrastructure.
- Provider-neutral advice: Hetzner, DigitalOcean, a hyperscaler or a mix – chosen for your workload.
- Performance included: Cloudflare, Varnish and server tuning are everyday work for us.
- Open-source first: portable tools and configuration keep you free to move again later.
- Fair pricing: premium work without premium prices, from Banja Luka, working remotely with clients locally and internationally – read more about CodeWiz.
Frequently Asked Questions
How much does a cloud migration cost?
It depends on the number of systems, the amount of data and how much downtime is acceptable. Moving one website with a database is a small project; several applications with zero-downtime replication is a larger one. You get a clear estimate after the assessment, with current and future monthly infrastructure costs side by side.
Will my website be offline during the migration?
Usually not, or only for a few minutes. With Cloudflare in front, incremental file syncs and database replication, the switch itself takes seconds. Where a short maintenance window is simpler and acceptable, we schedule it for your lowest-traffic hours.
Is Hetzner reliable enough for production?
Yes, for the vast majority of web workloads. As with any provider, reliability comes from architecture: backups in a separate location, monitoring, and redundancy where the business requires it. We design those in rather than relying on a single server.
How long does a migration take?
A single site or application can often be assessed, rehearsed and migrated within one to two weeks. Larger systems with several services and big databases take longer, mostly because of rehearsals and verification rather than the move itself.
Should I move from AWS to Hetzner or DigitalOcean?
If your workload is mostly plain compute, databases and storage, moving can cut costs substantially. If you rely heavily on AWS-specific managed services, a partial move or staying put may be wiser. The assessment tells you which with real numbers.
Ready to Plan Your Cloud Migration?
Tell us what you run today and what is not working – cost, speed or reliability – and we will propose a migration plan with a clear target architecture and timeline. Contact us to start with an assessment, or explore our cloud migration services.