Nobody mapped the dependencies
The application moves cleanly, then fails because it quietly relied on a file share, a scheduled job or a server nobody documented.
Fix: dependency discovery first
Awards & Recognitions
Cloud migration
Move to the cloud without putting production at risk
Assessment through cutover on AWS, Azure and Google Cloud — wave-planned, automated with Terraform, gated on rollback, and handed to a team that stays on to run it.
Every environment rebuilt as code, not clicked together
Rollback tested before any production wave
Data centre, hyperscaler or hybrid — we cover all three
Get a free migration assessment
A 5-day review: what moves, what doesn’t, what it costs. No obligation.
NDA on request. No spam, ever.
Destinations we migrate to
AWS
Microsoft Azure
Google Cloud
Oracle Cloud
Private & hybrid
The method
Bulk data moves first. The window carries the delta.
Everything heavy is pre-seeded and kept continuously in sync for days or weeks beforehand. What happens inside the maintenance window is small, rehearsed and reversible.
Source estate
Live, stateful, still serving
Databases, persistent volumes, workflow state and VMs — untouched and writable throughout.
Weeks before
Pre-seed & replicate
Per-store replication runs continuously — cross-cluster, logical, binlog, standby and replica-set sync — with lag measured under real load.
The window
Final delta, validate, decide
Minutes, not hours. Smoke tests gate the writes, and the source stays intact so rollback remains real.
Why migrations go wrong
Four failures we plan around
Migrations rarely fail on the technology. They fail on what nobody mapped first.
Lift-and-shift, then the bill arrives
Oversized instances sized for peak on-premise load run 24/7 in the cloud, and the business case evaporates in month two.
Fix: rightsizing before cutover
No way back
Cutover starts on a Friday night with no tested rollback, and the decision to abort has to be made under pressure at 3am.
Fix: rollback tested per wave
Compliance found out late
Residency, encryption and audit requirements surface after the landing zone is built, forcing expensive rework.
Fix: controls set at design
Migration strategy
Six ways to move a workload. We choose per application.
Lift-and-shift everything and you inherit every legacy problem at cloud prices. We classify each workload before anything moves.
Portfolio decisions
Migration paths
More change →
Portfolio decision
Retain
Leave it where it is, supported. Regulated data, plant-floor systems and hardware-bound workloads often should not move at all — we build and operate physical estates too, so what stays behind stays supported.
Best when
Compliance or physical constraints apply
Effort
No move
Portfolio decision
Retire
Switch it off. Most estates carry workloads nobody uses any more, and every one you retire removes migration cost and future licence spend.
Best when
Usage analysis shows no real consumers
Effort
Cheapest
Migration path
Rehost
Move the workload as-is onto cloud infrastructure. Fastest route, least optimisation — the right call when a deadline or data-centre exit drives the timeline.
Best when
Stable apps, hard deadlines, lease expiry
Effort
Low effort
Migration path
Replatform
Keep the application largely intact but swap components for managed equivalents — self-managed database to RDS or Azure SQL, VMs to containers.
Best when
You want cloud benefits without a rewrite
Effort
Medium effort
Migration path
Refactor
Restructure parts of the application to use cloud-native services properly — containerisation, managed queues, autoscaling, externalised state.
Best when
Scaling pain or high change frequency
Effort
High effort
Migration path
Rearchitect
Rebuild the application around a different architecture, typically decomposing a monolith into services with independent deployment.
Best when
The current design blocks the roadmap
Effort
Highest effort
Scope of work
Four layers, each migrated differently
A database cutover and an application refactor are not the same job. We scope and sequence them separately — and every layer lands in a governed landing zone, with networking, identity, guardrails and cost controls set before the first workload arrives.
Infrastructure migration
Servers, storage, networking and identity rebuilt in the target cloud as code — repeatable, version-controlled, reviewable.
TerraformVPC & networkingIAMBastion access
Platform migration
Runtimes moved onto managed platforms — Kubernetes, App Service, container registries and the pipelines that feed them.
EKS / AKSContainerisationHelmECR / ACR
Database migration
Schema and data moved with replication, validation and a rehearsed cutover — multi-AZ, backed up and tested before go-live.
RDS / Azure SQLReplicationMulti-AZRestore testing
Application migration
The application itself rehosted, replatformed or refactored, with shared storage, sessions and configuration handled properly.
EFS / Azure FilesConfig & secretsSession stateLoad
testing
Migrations delivered
Workloads we have actually moved
Named references and architecture walkthroughs available under NDA.
Featured
Standalone server → AWS EKS
A legacy monolith rebuilt as code, then containerised
A CakePHP application running on a single Linux box moved onto Amazon EKS — with the entire target estate provisioned from scratch in Terraform: EKS cluster, ECR registry, a custom VPC with public and private subnets across multiple availability zones, RDS with multi-AZ and automated backups, EFS for shared pod storage, and bastion hosts for controlled private access.
100% IaC
Every resource in Terraform
Multi-AZ
HA across availability zones
Monolith → K8s
Containerised on EKS
In delivery
Healthcare · public → sovereign private cloud
A live Kubernetes healthcare platform moved off public cloud — three production namespaces, ~35 persistent volumes and an Oracle ERP.
Multi-terabyte databases, interdependent namespaces and a thirty-minute window change the method entirely. Bulk data is pre-seeded and continuously replicated ahead of time, single points of failure are remediated weeks earlier, and the whole cutover is rehearsed and timed before anyone commits to a date.
11.6 TiB
Search data in scope
15–30 min
Tolerated window
5 / 30 min
Target RPO / RTO
Large-estate principles
Prove before you promise
Target ready, not available
Move data ahead of the
window
Fix the fragile parts first
Rehearse, then decide on
evidence
Kubernetes on AWS
Production-grade EKS landing zone
A purpose-built VPC with segmented subnets and security groups, an EKS cluster, LoadBalancer services fronted by ELB, and Route 53 records mapping application hostnames — the standard target pattern for containerised workloads.
EKSVPCELBRoute 53
High availability · AWS
Rebuilt across two availability zones
The application deployed into two zones behind a load balancer, so a zone failure redirects traffic automatically and no single instance absorbs the surge — resilience designed in at migration, not retrofitted.
Multi-AZELBFailoverAutoscaling
Secure Azure landing
Isolated environment for a governed application
App Service Environment with Application Gateway and Web Application Firewall in front, integrated into the client landing zone and deployed through Azure DevOps — built for platform-level audit as well as application security.
ASE v3App GatewayWAFAzure
DevOps
From the work — artefacts from live migrations
Migration architecture. Source estate, per-workload replication path and target landing zone, agreed before any wave is scheduled.
Infrastructure as code. The target estate defined in Terraform — reviewable, repeatable and handed over at the end.
Replication under load. Lag measured against the agreed threshold — the number the go/no-go decision is made on.
How we run it
Seven phases, each gated on evidence
Every phase hands over verifiable evidence before the next begins. That is what turns a risky cutover into a controlled transition.
00
Contained proof of concept
Phase 0
The full toolchain exercised end to end on a smaller, contained workload — measuring real RPO and RTO, rehearsing rollback and producing the first runbook, before the production estate is touched.
Exit evidence
Measured RPO / RTORunbook v1Issue log
01
Target readiness
Phase 1
The destination made operational rather than merely available: observability, backup and recovery, registry, ingress, network paths, storage performance and access all validated with measurable evidence.
Exit evidence
Readiness recordStorage benchmarkThroughput
test
02
Replication setup
Phase 2
Bulk data pre-seeded and kept continuously in sync using the right mechanism per data store, with lag observed under realistic production load.
Exit evidence
Stable replicationLag figuresData
validation
03
Single-point-of-failure remediation
Phase 3
Any workload that cannot be safely moved as it stands is fixed on a dedicated track first — standing up replica sets and standby databases. These are never cutover-night fixes.
Exit evidence
HA implementedStandby validated
04
Full timed rehearsal
Phase 4
The entire cutover and rollback sequence run without business risk, timed, with named owners and pass or fail recorded per workload, and business smoke tests written and exercised.
Exit evidence
Timed runbookRollback rehearsedSmoke
tests
05
Production cutover
Phase 5
The agreed window executed against pre-agreed go/no-go gates, with the source estate preserved intact so rollback stays genuinely available throughout.
Exit evidence
Go-live decisionSmoke-test sign-off
06
Hypercare
Phase 6
A 48 to 72 hour stabilisation window with the source still standing, an incident log kept throughout, and decommissioning approved only in writing.
Exit evidence
Incident logDecommission approval
Why Orion
Why businesses choose Orion for cloud migration
Since 2012 we have moved production workloads for manufacturers, healthcare providers and regulated financial businesses — and stayed on to operate most of them afterwards.
CMMI-3 & ISO 27001
AWS · Azure · GCP · Oracle
Terraform-first delivery
Toronto practice · Canada
Cutover night, in your time zone
Migrations are the one project where the hard hours are non-negotiable. Our Toronto practice delivers onshore and nearshore — senior engineers under a Canadian contracting entity, on the call with you during the window, at North American rates.
Data residency, procurement policy and audit requirements are handled by the same team, while the offshore bench carries build volume in the weeks before.
Onshore
Canadian-resident engineers, Canadian contracting entity, data stays in-country.
Nearshore
Full overlap with US Eastern through Pacific during the cutover window.
Blended
Toronto leads the cutover, offshore carries build volume beforehand.
On site
Available across the GTA and the US Northeast for cutover weekends.
What is cloud migration?
Cloud migration is the process of moving applications, data and infrastructure from on-premise or co-located systems into a cloud platform — or between clouds. Done well it improves scalability, resilience and cost control. Done as a straight lift-and-shift, it usually just relocates the existing problems onto a metered bill.
Which migration strategy is right?
It varies per workload, which is why we classify each one against the six Rs — rehost, replatform, refactor, rearchitect, retire and retain. A stable internal app might rehost in a week; a customer-facing platform under load usually justifies replatforming or refactoring. Around a tenth of most estates turns out to be retirable, which is the cheapest migration there is.
How long does a migration take?
A single application typically moves in four to eight weeks including assessment. A full data-centre exit runs six to eighteen months, delivered in waves so business risk stays bounded. The assessment phase is what makes the estimate real — anyone quoting a timeline before seeing your dependency map is guessing.
How is data protected during the move?
Encrypted in transit and at rest, moved over private links rather than the public internet where the platform allows it, with access scoped and audited throughout. Residency requirements are set at landing-zone design, not patched afterwards, and every wave has a tested rollback before it runs.
Related services
What happens after cutover
A migration that ends at go-live is only half delivered. The same team can keep running it.
Cloud Managed Services
Day-two ownership of the estate you just moved — monitoring, patching, incident response, cost governance and DR testing under an agreed SLA.
Explore managed servicesHire DevOps engineers
Certified engineers embedded in your team to build the pipelines and infrastructure-as-code that keep the new estate reproducible.
Explore DevOps servicesFrequently asked
Cloud migration questions
Downtime, rollback, scope and what happens after go-live — the parts that decide whether a migration is low risk for you.
Every workload is classified against the six Rs during assessment — rehost, replatform, refactor, rearchitect, retire or retain — scored on business criticality, technical debt, compliance constraint and downtime tolerance. You approve the classification before any wave is planned.
Most workloads move with a short, scheduled window; some move with none at all using replication and DNS cutover. The honest answer depends on the database and the statefulness of the application, and we give you a per-workload figure in the assessment rather than a blanket promise.
Every wave has a tested rollback before it runs — not a documented intention, an exercised procedure. The source environment stays live and reversible until the acceptance criteria for that wave are signed off.
Yes. AWS to Azure, Azure to GCP, co-location to hyperscaler, or consolidation of several accounts into one governed landing zone. Cross-cloud work usually needs more refactoring than a data-centre exit, and the assessment will say so plainly.
They stay, and we run them. We build and operate physical estates as well as cloud, so a hybrid outcome is a supported destination rather than an admission of failure — same team, same runbooks, same escalation path.
Usually. Most clients move the new estate onto a managed services agreement so the team that designed the migration owns the operating outcome. If you would rather run it yourself, you get the Terraform, the runbooks and a documented handover.
AWS, Microsoft Azure, Google Cloud and Oracle Cloud, plus on-premise and hybrid environments including VMware, Proxmox and OpenStack.
Let’s talk
Start with the assessment
Five days, no cost, no obligation. You get a dependency map, a six-Rs classification for every workload, and a wave plan with indicative cost — yours to keep whether or not we run the migration.
No cost
No obligation
Yours to keep
What the assessment delivers
Duration
5 days
Dependency map
Full estate
Classification
Six Rs, every
workload
Wave plan
With indicative cost
