MANAGED CLOUD MIGRATION
Move anything to the cloud — without losing your compliance footing.
A passed audit before migration becomes a failed audit after. We re-map controls, preserve evidence, across AWS, Azure, or Google Cloud.
- AWS, Azure, Google Cloud
- SOC 2, ISO 27001, HIPAA, PCI-DSS, PIPEDA continuity
- Contract-defined Sev-1 response targets
- Continuous Wazuh + OpenVAS monitoring with senior on-call
- Workloads, databases, identity, integrations
The promise
Your audit doesn't migrate with the workload. Unless we do it.
The audit you passed in March doesn't migrate with the workload. The moment your data lands in a new cloud, every control mapping, evidence trail, and inheritance assumption changes. Three months later, your SOC 2 examiner asks for log retention proof from the cutover window and your team has nothing.
ThinSky migrates your solution components and your compliance posture together. Controls are re-mapped to the target cloud's native services before the wave fires. Evidence is captured at every step. The next audit window opens and you're ready for it — same firm, same scope, new infrastructure.
What we migrate
Solution components — every layer of your stack.
Heterogeneous environments don't fit one tool's idea of a workload. We move what you actually run.
Workloads
VMs, containers, and Kubernetes clusters running your line-of-business applications.
Databases
Oracle, SQL Server, PostgreSQL, MySQL, MongoDB — lift-and-shift or onto managed PaaS.
Identity systems
Active Directory, Okta tenants, Keycloak realms, certificate authorities, federation trusts.
Application tiers
Three-tier web stacks, message brokers, queue infrastructure, caching layers.
Integration brokers
Enterprise service buses, API gateways, managed file transfer platforms, EDI engines.
Appliances
Physical security appliances, network controllers, on-prem WAFs replaced with cloud-native equivalents.
SaaS handoffs
Moves from a hosted SaaS into a private deployment in your tenant, or the reverse.
Data lakes and analytics
Hadoop clusters, on-prem warehouses, BI platforms, ETL pipelines.
How it works
Three phases. One team across all three.
Your migration, in phases.
A staged path from your current estate to a managed setup — planned, executed in waves, and managed under continuous monitoring with senior on-call from the day after cutover.
Three to six weeks. Map every component, dependency, and inherited control. Risk model, target architecture, and a cutover plan with explicit rollback gates.
Wave-by-wave migration with rollback boundaries — if a control breaks, we revert without touching the next wave. Encryption and evidence capture verified per move.
Cutover is day one. Continuous monitoring starts at handoff — log analytics, vuln scanning, patching, drift detection with senior on-call. Compliance evidence maintained continuously, not at audit time.
Plan
Three to six weeks. We map every solution component, every dependency, every compliance control inherited from the current host. Discovery interviews with the operators, not just the architect. We model risk, design the target state, and write a cutover plan with explicit rollback gates.
Deliverables:
- Dependency map and target-state architecture, signed off by your team
- Certification gap analysis tied to your audit firm's evidence list
- Cutover runbook with wave sequencing, rollback boundaries, and roll-forward criteria
Execute
Migration runs in waves, not big-bang. Each wave has rollback boundaries — if a control breaks or a workload misbehaves, we revert without touching the next wave. Encryption-in-transit is verified for every component move. Evidence capture is automated, not reconstructed by hand after the fact.
Deliverables:
- Per-wave evidence pack — encryption verification, control re-map proof, validation logs
- Post-cutover SLO validation against the pre-migration baseline
- Rollback rehearsal artefacts retained for the next audit window
Manage
Cutover is day one, not delivery. Continuous monitoring with senior on-call starts at handoff — Wazuh-driven log analytics, OpenVAS-driven vulnerability scanning, patching, backup verification, secrets rotation, drift detection. Certification continuity is monitored continuously, not at audit time. Functional uptime and security posture sit on the same console.
Deliverables:
- Continuous Wazuh + OpenVAS monitoring with senior on-call and contract-defined Sev-1 response targets
- Monthly compliance posture report mapped to your active certifications
- Quarterly architecture review with drift remediation roadmap
Certification continuity
Certification continuity is designed in, not rebuilt after.
Your certification posture, kept continuous.
- SOC 2
- ISO 27001
- HIPAA
- PCI-DSS
- PIPEDA
SOC 2 Type II controls re-mapped to the target cloud's CC7.2 monitoring and CC8.1 change management services, with evidence captured per wave. ISO 27001:2022 Annex A controls inherited from cloud-native services and documented in your ISMS. HIPAA technical safeguards re-implemented with BAAs signed before any PHI moves. PCI-DSS v4.0 scope rebuilt under customised approach controls, with quarterly ASV evidence preserved. PIPEDA Canadian residency maintained — workloads pin to Canadian regions only.
The response promise
Sev-1 response on a contract-defined target.
Sev-1 is one of four things: customer-impacting downtime, a confirmed security incident, compliance-breaking configuration drift, or backup verification failure on a regulated workload. A senior on-call engineer responds to Sev-1 pages on the response target defined in your contract — and the escalation path is documented before cutover, not improvised during it.
ThinSky vs the alternatives
Three ways to move. One that owns the result.
| ThinSky | Big Four consulting | Commodity MSP | |
|---|---|---|---|
| Engagement model | Fixed-scope project, then a named ongoing team | Hourly partners and rotating subcontractors | Ticket queue with shift handoffs |
| Compliance ownership | Pre- and post-migration audit posture owned by us | Delivered to plan; audit response is a new SOW | Hosting only; compliance stays yours |
| Post-migration accountability | Same team operates what they built | Project closes; new SOW for operations | Operations begins when onboarding ends |
| Cloud neutrality | Recommendation falls out of the planning phase | Aligned to current strategic-partner MSA | Whatever is already in the data centre |
| SLA on incidents | Contract-defined Sev-1 response targets | None on the project; ticketing after close | Business hours typical, premium upcharge |
Honest answers
The five questions every CISO asks before signing.
Where does our data live during the migration itself?
We pin every transit and staging location to the customer-chosen region before the first wave fires. PIPEDA clients get Canadian regions only — ca-central-1, canadacentral, or northamerica-northeast1 — with documented data-flow maps for your privacy officer. No data leaves the chosen region for staging, testing, or DR replicas.
Production cannot go down. What's the realistic downtime per workload?
We design cutovers for minimal downtime — replication-and-promote for stateful databases, rehearsed against a clone before the production wave runs. Realistic downtime, RPO, and RTO are scoped per workload in the written plan, not promised in copy. Zero-downtime patterns exist for HA workloads when the architecture supports them.
Our SOC 2 audit window opens in 90 days. Do we wait?
No. We sequence the migration around your audit window, not against it. If timing is tight, we either complete pre-audit waves and pause execution through the audit, or migrate non-scoped components first and run the in-scope wave after the audit closes. Your examiner gets one consistent control environment to evaluate, not a half-state.
Doesn't migrating to AWS plus Azure plus GCP create more lock-in, not less?
It can, if you copy each cloud's proprietary services into your architecture without a portability plan. We pick the cloud that fits the workload, not the workload that fits a cloud, and we document the portable equivalent for every managed service we use. The lock-in conversation gets a written answer, not a hand-wave.
If we want to end the contract, what happens to operations?
Operational handback is in every contract by default. We document the runbook, the alert routing, the on-call rotation, and the access topology, then run a 30-day shadow with your incoming team. Source code, dashboards, runbooks, and infrastructure-as-code repos transfer to you. If you leave, you can actually leave.
See the plan before you commit to the move.
Send a workload inventory. We come back with a dependency map, a certification gap analysis, and a written cutover plan in two weeks — no commitment required.
Start with a Plan →