AWS Migration Services for US & EU Workloads

All seven (Retire, Retain, Relocate, Rehost, Repurchase, Replatform, Refactor) but we explicitly resist defaulting to Rehost. Decision input is an AWS Migration Hub Strategy Recommendations run plus our own dependency map from Application Discovery Service agents. We score each workload on five axes: blast radius, change frequency, runtime cost on EC2 vs managed equivalent, license entanglement, and team familiarity. Stateless web tiers usually Replatform onto ECS Fargate or App Runner. Oracle/SQL Server with heavy PL/SQL go Refactor to Aurora PostgreSQL via Babelfish or DMS + SCT. COTS without an exit goes Rehost via MGN, then revisited 12 months later.

Terraform by default, occasionally Pulumi when the client team prefers TypeScript end-to-end. We never use ClickOps for foundation. The landing zone is AWS Control Tower with customizations: separate OUs for Security, Audit, Log Archive, SharedServices, Workloads (dev/stage/prod), and Sandbox. Identity is IAM Identity Center federated to your IdP (Okta, Entra ID, Google Workspace). Network is a Transit Gateway hub-spoke with centralized inspection VPC running AWS Network Firewall. Everything is in Terraform modules versioned in your repo — you own the code on day one, not us.

Workloads with EU personal data land in eu-central-1 (Frankfurt), eu-west-1 (Ireland), or the AWS European Sovereign Cloud where appropriate. We pin services to those regions via SCPs at the OU level — a developer cannot accidentally spin up a Bedrock model in us-east-1. For Schrems II compliance we use AWS Nitro Enclaves where attestable confidential compute is required, KMS with customer-managed CMKs (and XKS / external key store for sovereignty-critical workloads), and SCCs in the DPA. CloudTrail and Config logs are encrypted with separate keys and replicated cross-region inside the EU only.

We instrument Cost and Usage Reports into Athena + QuickSight on day one and tag every resource with cost-center, environment, and service via Terraform-enforced policy. The FinOps cadence is weekly: anomaly detection via AWS Cost Anomaly Detection, rightsizing recommendations from Compute Optimizer, Savings Plans coverage tracking, and a monthly written report. Typical savings on a lift-and-shift baseline are 28–35 percent within 90 days (Graviton migration on stateless tiers, S3 Intelligent-Tiering on cold data, Aurora I/O-Optimized on write-heavy databases, Spot for batch on EKS via Karpenter).

Yes — co-delivery is our default model. Your team owns business logic, application changes and final cutover decisions. Our team owns landing zone, network, security baseline, MGN/DMS pipelines, observability stack and the runbooks. We pair-program the Terraform, run weekly architecture review with your tech leads, and hand off via a 30-day shadow period. By the end of the engagement your engineers are reviewing our PRs, not the other way round. No vendor lock-in to YuSMP after the sprint ends — that is contractual.

Fixed-scope, all-in USD pricing: individual services from $200, a lift-and-shift from $1,800, a re-platform from $4,100, and a full exit off AWS/Azure/GCP from $5,800. You see the line-item budget at the end of discovery and sign off before any code is written — no recruitment markup, no tool surcharges, and cloud fees run on your own accounts so you keep the cost lever. Timelines scale with estate size: a 200-server estate typically moves in 4–6 months end-to-end, with re-platform and refactor work quoted per wave.

For most workloads, minutes — not hours. MGN keeps a continuous block-level replica of the source running in AWS, so the cutover is a short final sync plus a DNS or load-balancer switch inside a planned window. Databases move with DMS in CDC (change-data-capture) mode: we replicate the bulk load ahead of time, then keep it in sync until the switch, which cuts the actual downtime to the time it takes to stop writes and flip the endpoint. Every wave has a rehearsed rollback path, so if a validation check fails we revert to the source with no data loss. Truly zero-downtime cutovers are possible for stateless tiers behind a load balancer; we tell you upfront which workloads can and cannot achieve it.

Not necessarily. Where the schema and workload allow, we refactor SQL Server to Aurora PostgreSQL using Babelfish (which speaks the TDS wire protocol, so many applications connect unchanged) and Oracle to Aurora via DMS + Schema Conversion Tool, retiring the commercial license entirely. Where a refactor is not viable in this phase — heavy PL/SQL, third-party COTS dependencies — you can bring your own license (BYOL) onto EC2 dedicated hosts or run RDS for Oracle/SQL Server under license-included pricing, and we flag it as a refactor candidate for a later wave. The database strategy, license-cost delta and effort estimate are part of the discovery deliverable, so the trade-off is a decision you make with numbers, not a surprise.

Layered safety. The source database is never decommissioned until post-cutover validation passes — DMS replicates rather than moves, so the original stays intact and writable as a fallback. We run row-count and checksum reconciliation between source and target before every cutover, keep the CDC stream live through the switch, and snapshot both sides immediately before and after. For high-stakes systems we do a full rehearsal against a clone first. Nothing is deleted on the source estate until you sign off that the AWS target is correct and stable.

Per workload, driven by traffic shape and operational fit, not fashion. Spiky or event-driven workloads with clean statelessness go to Lambda or App Runner, where you pay per request and scale to zero. Steady services with container images and a team that wants Kubernetes go to EKS with Karpenter; teams that want containers without cluster ops go to ECS Fargate. EC2 stays for licensing-bound COTS, GPU workloads, or software that assumes a persistent host. We model the three-year runtime cost of each option during discovery, so the choice is defensible on both engineering and FinOps grounds — and nothing forces one pattern across the whole estate.

DR is part of the landing-zone design, not an afterthought. We set an RPO/RTO target per workload tier and implement to it: AWS Backup with cross-region (and, in the EU, EU-only) vaults, Aurora automated backups plus point-in-time recovery, and cross-region read replicas or pilot-light/warm-standby topologies for tier-1 systems. Recovery runbooks are written and, for critical workloads, DR is game-day tested so the RTO is a measured number rather than a hope. Backup policies and retention are codified in Terraform, so they apply automatically to new resources instead of relying on someone remembering to enable them.

Yes, and it is a common starting point. We begin with an assessment of the existing landing zone and any in-progress waves: what is Terraform vs ClickOps, whether the account structure and guardrails are sound, and where technical debt has already accumulated. You get an honest written read — sometimes we adopt and extend what exists, sometimes we recommend re-laying specific foundations, and we tell you which and why. Because everything we build lands as Terraform in your repo, there is no lock-in on our side either: the next team after us inherits code, not a black box.