aws
us-east-1
100% traffic
cdc
gcp
us-central1
0% traffic
› aws us-east-1 → gcp us-central1 · 5 components · diff ok
components5 mapped
api gateway
queued
postgres-primary
queued
redis-cache
queued
object-store
queued
secrets
queued
traffic
100/0
Atmos/A product from GroupLabsCross cloud migration
Move your workload from one cloud to another. Without the rewrite.
Atmos maps your services, data, and config to the equivalent primitives on a second cloud, mirrors them in the background, and shifts traffic over when you say go.
No frozen feature work. No new abstraction to learn. The cutover is a button.
- Clouds
- AWS · GCP · Azure
- Cutover window
- < 5 min
- App rewrites
- none required
- Rollback
- one command
When this matters
If 'multi-cloud' is a strategy slide and not a runbook.
Atmos is for teams whose workload runs in one place today and needs to run somewhere else next month, without freezing roadmap to do it.
01
A cloud bill that just keeps climbing
Egress, reserved instances you no longer use, a database tier you outgrew. Finance keeps asking. Engineering keeps quoting a quarter to move.
02
Procurement bought a different cloud
The committed-spend deal is on the other provider now. The workload still runs where it always did, and someone has to bridge the gap.
03
A region keeps melting down
Provider-wide incidents, capacity shortages, regulatory pressure. You want the option to be somewhere else by Friday, not next quarter.
04
A customer requires a specific cloud
Government, defence, healthcare, EU residency. The deal is yours if the workload runs in the right tenant. The workload is on the wrong one.
How it works
From snapshot to second cloud. Without freezing the roadmap.
Atmos runs alongside your live workload. Mirror, drill, cut over. Each step is observable and reversible.
01Phase
Map the workload
Atmos reads your live infra (services, data stores, queues, secrets, network) and produces a target-cloud mapping. Where the equivalent exists, it picks it. Where it does not, it tells you before you start.
02Phase
Mirror in the background
Stateless services are recreated on the target. Databases stream changes through CDC. Object storage syncs continuously. Source keeps serving the whole time.
03Phase
Run a shadow drill
A copy of production traffic plays against the target side. Diffs in latency, error rate, and response shape are reported before any user touches it.
04Phase
Cut over and watch
DNS shifts in weighted steps, not a single flip. If health checks regress, Atmos halts the shift and tells you why. Rollback is one command.
What ships
A migration that stays observable end to end.
Three things you can hand to the engineer who has to make this call on a Tuesday.
- 01
A mapping report your team can challenge
Every component on the source side gets paired with a target primitive, or flagged. You see shape diffs, parity gaps, and capacity holes before the first byte moves.
Mapping report · pre-cutover5/6 parity1 shape diffapi-gateway
aws · alb → gcp · l7-lb
p95 +4msparitypostgres-primary
rds · 15.4 → cloudsql · 15.4
lag 0.4sparityredis-cache
elasticache · 7.2 → memorystore · 7.2
evictions 0parityobject-store
s3 · standard → gcs · standard
38% copiedin progressevent-bus
sns + sqs → pub/sub
shape diff: orderingreviewsecrets
secretsmanager → secret-manager
parityparity
- 02
Continuous mirroring while production runs
CDC for stateful systems. Object sync for blob storage. Config and secrets reconciled. Source keeps serving until you decide otherwise. There is no maintenance window.
- 03
A cutover you can pause, slow down, or undo
DNS weights move in steps you control. Health checks gate every step. If anything regresses, Atmos halts and points at the offending signal. Rollback to the source side is a single command.
aws
us-east-1
100% traffic
cdc
gcp
us-central1
0% traffic
› aws us-east-1 → gcp us-central1 · 5 components · diff ok
components5 mapped
api gateway
queued
postgres-primary
queued
redis-cache
queued
object-store
queued
secrets
queued
traffic
100/0
Why Atmos
Most cloud migrations die in the discovery phase.
Atmos starts from the running system, not the wiki. The plan it produces matches what you actually have.
01
It treats every cloud as a target, not a religion.
AWS, GCP, Azure, and the on-prem rack you forgot you owned. Atmos maps primitives, not branding. The thing that moves is your workload, not your team's vocabulary.
02
It survives the parts you forgot about.
The cron job nobody documented. The legacy queue. The IAM role with one consumer. Atmos finds them in the live environment, not the architecture diagram, and refuses to cut over until each is accounted for.
What Atmos isn't
Three things people assume, and the actual answer.
Cross-cloud is a crowded category full of bad metaphors. Here's what makes Atmos structurally different.
01
Not a new abstraction
You don't rewrite your stack into Atmos primitives. Atmos talks to AWS, GCP, and Azure in their native API. Your code stays your code on the other side.
02
Not a lift-and-shift service
A consultant in a slide deck migrates VMs. Atmos migrates the running shape of your system (services, state, secrets, traffic) and verifies it before the cutover.
03
Not a federation layer
No proxy in the hot path. No new control plane to keep alive forever. Atmos runs during the move, watches for a while after, and gets out of the way.
Common questions
What teams ask before they schedule a cutover.
01Which clouds does Atmos support?
AWS, GCP, and Azure as both source and target. On-prem and bare-metal Kubernetes are supported as either side. Cross-region within a single cloud uses the same machinery. The controller does not care whether the destination is a different vendor or a different account.
02How long does a migration take?
The mirror phase runs as long as your largest stateful system needs to catch up. Typically hours to days for production-scale databases. The cutover itself is minutes. The roadmap does not stop while either is happening.
03What about services with no equivalent on the other side?
Atmos flags them in the mapping report and refuses to schedule a cutover until each has an explicit decision: a managed equivalent, a self-hosted alternative, or an explicit accept-the-gap. Surprises at cutover are the failure mode we built around.
04Can we roll back?
Yes. The source environment stays warm during shadow and weighted cutover. Reversing direction is a single command and shifts traffic back the way it came. Mirroring runs in both directions while both sides are warm, so no writes are lost.
05How is data kept consistent during the move?
Stateful systems use change-data-capture so the target lags the source by seconds, not hours. Object stores use continuous sync. At cutover, Atmos quiesces writes on the source, drains in-flight requests, lets the target catch up, then opens the target side. The pause is visible in the dashboard and typically under a second.
Pricing
Pay for bytes moved, not seats sold.
Atmos charges by what gets mirrored and cut over. The incentive sits with the team doing the migration, not the one buying the license.
- One source → target pair
- Mapping report and shadow drill
- Direct line to the engineering team
- Pricing fixed at beta rate after launch
- Unlimited workloads and target pairs
- CDC, object sync, secrets parity
- Shadow drill + weighted cutover
- SOC2-ready data handling
- Email + Slack support
- Self-hosted or VPC-isolated
- Custom data retention and audit
- SSO, SAML, SCIM
- Dedicated solutions engineer
- Procurement-friendly contracts
Plan 01
Pilot
Free · 30 days
For one workload, one direction
Drop Atmos in front of one production workload. Co-built mapping, supervised cutover, and pricing locked in for the first year.
Recommended
Plan 02
Team
From $1,500/mo
For teams running across more than one cloud
Production install across your fleet. Usage-based on bytes mirrored and cutovers scheduled, not per-engineer seats.
Plan 03
Enterprise
Custom
Self-hosted control plane
Single-tenant deployment in your VPC. Custom retention, dedicated SRE, procurement-friendly contracts. For regulated environments.
§ 03 · Engagement intake
01 / Start a brief
Talk to the people who’ll do the work.
We staff small and senior, scope by phase, and end on a written deliverable. We don’t sell decks or hours.
If we’re not the right team for the job, we say so on the first call. The bar is production, not pitch.
Compose a brief30 min · intro
WGS84YYC / YUL
CalgaryYYC
51.05°N · 114.07°W
MontrealYUL
45.51°N · 73.55°W
Δ 3,020 km
02 / Where to find us
02
+1 (825) 365-9891Montreal, Quebec
Satellite office- Lat / Lng
- 45.5089°N · 73.5542°W
- Local
- —:— EST · UTC−05