Cloud Modernisation on AWS

The AWS assessment produces two things: a wave plan the delivery team can execute, and a cost model finance can hold us to. Both are built from observed behaviour rather than from the specification of the current hardware.

• Discovery and dependency analysis consolidated in AWS Migration Hub, reconciled with interviews so undocumented integrations surface before a wave is planned.
• Account and organisational unit design workshop covering environment separation, shared services, logging and how new accounts will be requested and approved.
• Right-sizing from observed utilisation, with instance family, purchase option and storage class choices priced against the current hosting and support cost.
• Data transfer modelling for chatty applications, so cross-zone and egress charges appear in the business case rather than in the first invoice.
• Licensing review for Windows and commercial database workloads, including where a move to Amazon Aurora or Amazon RDS changes the licence position.
• Recovery objectives agreed per workload and translated into an AWS Backup policy and, where warranted, AWS Elastic Disaster Recovery replication.

We build the account foundation, network and guardrails before workloads land, then migrate in waves that each end in a verifiable state. Modernisation of individual applications is sequenced after the move unless the business case demands otherwise.

• Landing zone established with AWS Control Tower and AWS Organizations, including organisational units, service control policies, centralised logging and a repeatable account vending process.
• Amazon VPC design with segmented subnets, controlled egress, interface endpoints for platform services and connectivity through AWS Direct Connect or VPN, tested against the applications that will cross it.
• Rehost waves delivered with AWS Application Migration Service, using test cut-overs into an isolated subnet so owners validate their systems with real data before the production window.
• Replatforming onto Amazon ECS with AWS Fargate, AWS App Runner or AWS Lambda based on request pattern, runtime support and the team's operating capability, with the choice documented per workload.
• Database migration to Amazon RDS, Amazon Aurora or Amazon DynamoDB, including engine compatibility assessment, performance baselining and a rehearsed cut-over with a validation step.
• Traffic entry standardised through Elastic Load Balancing and Amazon CloudFront so certificates, health checks and caching behaviour are consistent rather than configured per application.

Guardrails go into the organisation before workloads arrive, so a new account starts compliant instead of being remediated later. Controls are preventive where the risk warrants it and detective everywhere else.

• Service control policies at organisational unit level restricting regions, denying disablement of logging, and blocking resource types the organisation has decided not to run.
• Centralised logging and configuration recording, with AWS Config rules evaluating drift and non-compliant resources reported to a named owner rather than to a shared inbox.
• Least-privilege role design with federated sign-in, no long-lived access keys for human users, and permission boundaries on roles that teams can create themselves.
• Encryption enforced for storage, databases and backups with customer-managed keys where key control is a requirement, and key usage logged.
• Network exposure review covering security groups, public subnets, load balancer listeners and object storage access, repeated as a check at the end of each migration wave.
• Control mapping showing how the deployed AWS configuration supports the Essential Eight or ISO 27001 controls you are working towards, and which gaps remain process responsibilities.

The account model only works if your team can operate it, including creating the next account correctly. Enablement is built around what they will do in the first months after go-live.

• An account request and vending runbook covering naming, organisational unit placement, baseline guardrails, budget setup and who approves each step.
• Hands-on sessions in the real environment covering restore from AWS Backup, a failover rehearsal, scaling an Amazon ECS service and interpreting an Amazon CloudWatch alarm back to a cause.
• Cost ownership handover using AWS Cost Explorer views and AWS Budgets scoped per team, so each owner sees only their own spend and its trend.
• Documented escalation paths separating platform issues, application issues and AWS support cases, with the diagnostic detail required for each.
• A joint dry run of the first post-migration change, executed by your engineers while we observe, followed by a review of what the runbooks missed.
• Source environment decommissioning checklist covering data retention, contract termination dates, backup retention and the sign-off required before equipment is released.

After migration we can keep running the AWS platform with you under an agreed service schedule, maintaining the guardrails, resilience testing and cost discipline once the project team has stood down.

• Amazon CloudWatch alarm tuning and triage, with coverage extended as workloads change and noisy alarms retired rather than muted.
• AWS Config compliance reporting covering drift, newly non-compliant resources and guardrail exceptions approaching their agreed expiry.
• Scheduled restore tests from AWS Backup and periodic AWS Elastic Disaster Recovery failover rehearsals, with the result and any remediation recorded.
• Monthly cost review using AWS Cost Explorer and AWS Budgets, covering spend by account and tag, commitment coverage, idle resources and specific right-sizing actions with the saving quantified.
• Patch and image currency management for Amazon EC2 instances, container base images and managed engine versions against an approved maintenance calendar.
• A prioritised improvement backlog covering resilience gaps, cost actions and workloads still worth moving off instances.