Cloud migration
Cloud migration in Israel
An orderly move of existing systems to the cloud — physical servers, shared hosting or another provider — with a written plan, a rehearsed cutover and a way back at every stage. No all-nighters and no surprises on the bill.
What moves, and how
Servers and applications
application servers, web servers and internal services move to EC2, ECS or Kubernetes, whichever suits the system.
Databases
migration to RDS or Aurora with replication set up first, so actual downtime is measured in minutes.
Files and storage
file volumes move to S3 or EFS, including permissions, backups and retention policy.
Network and DNS
VPC design, connectivity back to the office network if needed, and a scheduled DNS switch with a short TTL.
Security and permissions
permissions are cleaned up during the move instead of copying old, over-broad access.
Post-migration tuning
right-sizing after two weeks of real data, so you stop paying for what you do not use.
How it works
- 1System survey — what runs, what depends on what, what may be taken down and when the quiet window is.
- 2Migration plan — a document with the order of operations, expected downtime, ownership and a rollback plan.
- 3Build in the cloud — the new environment is built as code alongside the old one, without touching production.
- 4Dry run — a full rehearsal of the cutover on copied data, including acceptance tests.
- 5Cutover and watch — the move itself, followed by a few days of close monitoring until everything is steady.
What usually surprises people
- Software licences that do not transfer to the cloud as they are.
- Fixed IP addresses that other systems quietly depend on.
- Scheduled jobs nobody remembers, still running from an old server.
- Data transfer costs out of the cloud, easy to miss when planning.
Related
- AWS cloud services — the environment you move into.
- Cost optimization — after the move, once there is real data.
- DevOps and CI/CD — so releases after the migration are automated.
Frequently asked questions
- How long will our system be down?
- Usually between a few minutes and an hour, because data is replicated in advance. Some systems can move with no downtime at all; others need a planned night window.
- Can we roll back if something goes wrong?
- Yes. The old environment stays live until the new one is confirmed stable, and the rollback plan is written before the cutover rather than during it.
- What will the cloud cost us after the migration?
- A monthly estimate is produced during planning, based on your real load. After two weeks in the cloud there is an optimization round, which usually brings it down further.
- Do we have to move everything at once?
- No, and usually it is better not to. Start with one less critical system, learn from it, then continue. Staying hybrid for a long period is also a valid choice.
Tell me what you are running today
A short call, then a written plan with a cost estimate and a fixed scope. No obligation.