A lot of Greek companies still run production on a VPS, a local hosting provider or a rack of servers in the office. It works until it doesn't: the server is full, the one person who set it up has left, or a large customer asks where the backups are and what happens if the data centre goes down.
Moving to the cloud fixes those problems, but only if the move is planned. Here is the checklist we use, in the order we use it.
1. Decide whether the move is worth it
Before any technical work, write down why you are moving and what it should cost afterwards. Good reasons: you need redundancy you can't build yourself, you are growing faster than your servers, a customer or regulator requires it, or the people who know the old setup are leaving. A weak reason: "everyone is on the cloud". A single well-run VPS can be cheaper than a badly designed cloud setup, and a migration that doubles your bill without improving reliability is a step backwards.
Get a rough monthly estimate of the target setup before you start, and decide who will own that number after go-live.
2. Inventory everything
This is the step that decides whether cutover day is calm. List every component, with an owner next to each one:
- Servers and what runs on them, including the things nobody thinks of as "the app": cron jobs, queue workers, report scripts, the FTP server a partner still uses.
- Databases, their size, how fast they change, and who reads from them directly.
- DNS records, TLS certificates and where they are renewed.
- Outbound integrations: payment providers, banking and government APIs, SMS and email providers. Several of these whitelist your current IP address, and changing it can take days.
- Inbound dependencies: partners, mobile apps or devices that call you by a fixed IP or hostname.
- Backups, where they go, and when one was last actually restored.
The IP whitelists catch Greek companies more than anything else. Start those requests early.
3. Pick the region
For AWS, the usual choices for Greek workloads are Frankfurt (eu-central-1) and Milan (eu-south-1). Both keep data in the EU and are a few tens of milliseconds from Athens, which is fine for almost every web application. Frankfurt has the widest service catalogue and usually gets new features first.
AWS has also announced a Local Zone in Athens. A Local Zone extends a parent region with compute and storage physically close to your users, but it offers a subset of services. It makes sense for latency-sensitive parts of a system, such as real-time processing or data that must stay in the country, while the rest of the platform runs in the parent region. Check which services are available there before designing around it.
On GCP and Azure the logic is the same: choose the nearest EU region with the services you need, and keep everything, including logs and backups, in the EU. Our AWS vs GCP vs Azure comparison covers the provider choice itself.
4. Set up the foundations before anything moves
- Accounts. Separate production from everything else from the start. On AWS that means AWS Organizations with SSO and no shared root credentials.
- Network. Private subnets for databases and services, a VPN back to anything that stays on-prem, and gateway endpoints for S3 so you don't pay NAT charges for traffic that never needed to leave.
- Infrastructure as code. Everything in Terraform from day one, with state split sensibly. Click-ops during a migration becomes the mystery infrastructure of next year.
- Logging and monitoring. Central logs and basic alerts before the first production request arrives, so you can compare old and new.
5. Choose compute: VMs, ECS or Kubernetes
This is where many migrations overspend. The honest guidance:
- Virtual machines (EC2) are the fastest "lift and shift" for legacy software that expects a server. Fine as a first step; plan to containerise later if it pays off.
- Managed containers (ECS with Fargate, Cloud Run) suit most startups and SMEs with a handful of services. There is no cluster to run and no control-plane fee.
- Kubernetes (EKS, GKE, AKS) pays off with many services, several teams deploying independently, or a need for the same platform across clouds. EKS charges a control-plane fee per cluster, and the operational effort is real.
If you are moving five services, you probably don't need Kubernetes yet. If you are moving fifty, you probably do.
6. Plan the database cutover
The database decides how much downtime you have. Copying a dump during a maintenance window is simple and fine for small databases. For anything larger or busier, replicate continuously into the new managed database (with native replication or AWS Database Migration Service), let it catch up, then switch over with only seconds to minutes of write freeze.
- Test the restore of a full backup into the new database before cutover, and time it.
- Check character sets, collations and time zones. Greek text and timestamps are where silent data bugs appear.
- Decide in advance what "rollback" means once writes have gone to the new database.
7. Rehearse, then cut over
- Lower DNS TTLs to a minute or two at least a day before.
- Do a full dry run in staging, with a stopwatch and the actual runbook.
- On the day: freeze writes, let replication catch up, switch DNS or the load balancer, and verify with real requests.
- Keep the old environment running and untouched for a few days in case you need to go back.
Pick a quiet time for your business, not for the engineers. For many Greek consumer products that is a weekday morning, not a Friday night.
8. The first 30 days
- Set budgets and billing alerts on day one, and look at the bill every week for the first month.
- Right-size once real traffic shows what you need; first estimates are usually too large.
- Buy Savings Plans or committed-use discounts only after usage stabilises.
- Switch off the old environment and cancel the old contracts. It is surprisingly easy to pay for both for a year.
- Run a short review: what surprised you, and what goes into the runbook for next time.
How long it takes
A single application with one database typically moves in a few weeks. A company with several services, environments and external integrations usually takes two to six months, most of it spent on inventory, foundations and testing rather than on the cutover itself. The inventory in step 2 is what gives you a realistic estimate.
Frequently asked questions
How long does a cloud migration take?
A single application with one database usually takes a few weeks. Companies with several services, environments and integrations typically need two to six months, mostly for inventory, foundations and testing.
Should a startup use ECS or Kubernetes?
With a handful of services, managed containers such as ECS on Fargate or Cloud Run are usually cheaper and simpler. Kubernetes pays off with many services and several teams deploying independently.
Which AWS region is best for Greece?
Frankfurt (eu-central-1) and Milan (eu-south-1) are the usual choices, both in the EU and a few tens of milliseconds from Athens. The Athens Local Zone can host latency-sensitive parts of a system alongside a parent region.