Rekhiv Soft Ltd

Migration to AWS

Move servers, databases and applications to AWS with a tested plan, a rehearsal and a way back if something goes wrong.

Book an introductory call
Typical target layout for a migrated workload An AWS region in London. The workload account holds a VPC across two availability zones, each with a public subnet for the load balancer, a private subnet for application containers and an isolated subnet for an encrypted database and its standby. Logs flow to a separate log archive account, and security findings flow to a separate security account that alerts your team. AWS Region: eu-west-2 (London) Workload account VPC 10.0.0.0/16 Availability Zone A Availability Zone B Public subnet Load balancer Private subnet App containers Isolated subnet Database, KMS-encrypted Public subnet Load balancer Private subnet App containers Isolated subnet Database standby logs findings Log Archive account Organisation CloudTrail S3 with Object Lock AWS Config history Write-once, kept for audits Audit account GuardDuty Security Hub Alerts to your team Separate from day-to-day access
A typical target layout after migration

Each application runs across two Availability Zones in the London region, with the database in an isolated subnet. Logs and security findings leave the workload account, so they survive even if that account is compromised.

What's included

Most migration problems come from surprises: a forgotten dependency, or a database that takes longer to copy than expected. This work removes those surprises before cut-over day.

  • An inventory of servers, databases and the dependencies between them
  • A wave plan that moves the lowest-risk workloads first
  • A target architecture for each workload in the London region
  • A rehearsal in a non-production account
  • A cut-over runbook with rollback steps
  • A post-migration check of cost and performance

Typical tools

AWS Application Migration Service, AWS Database Migration Service

How it works

  1. Discover

    An inventory of what you run today, how the parts depend on each other, and how big each one is.

  2. Plan

    Workloads grouped into waves, each with a target design, a cut-over window and rollback steps.

  3. Rehearse

    A practice migration in a non-production account, timed, so cut-over day holds no surprises.

  4. Cut over

    Each wave moved and checked, with the old system kept ready until the new one is confirmed working.

Questions

More answers on the services page, or ask us directly.

Will there be downtime?

Most workloads can move with a short cut-over window planned outside your busy hours. The plan states the expected window for each workload before anything moves.

What if something goes wrong on the day?

Every cut-over has a tested rollback step. The old system stays ready until the new one is confirmed working.

Do we have to move everything at once?

No. Workloads move in waves, starting with the lowest risk, so your team builds confidence before the important systems move.

Talk through your migration to aws needs

Tell us what you run today and what you want to change. We'll suggest where to start.

Book an introductory call