Cloud & DevOps
Workloads moved to the cloud one decision at a time, releases through a pipeline with a rollback someone has actually tried, and access rules kept in code rather than in a review document.
The release happens on a Saturday because only one person knows the order of the steps. Staging stopped matching production sometime last year. The cloud account opened for one project now hosts five, and nobody can say which roles read production data. Meanwhile a lease or a hardware quote is pushing the next migration onto a deadline. None of this was designed. It built up one reasonable shortcut at a time, and it can be taken apart the same way.
Decide workload by workload, not all at once
Lift and shift
Move each machine as it is onto a cloud server of about the same size. It meets the deadline, changes nothing in the application, and can be reversed.
- Nothing in the application changes, so the test surface stays small
- A lease or hardware deadline is met without rewriting anything
- You can move back if the platform proves the wrong choice
- Costs stay close to the old setup, because the old sizing moves too
Re-architect for the platform
Rebuild the workload around what the platform offers: managed databases, object storage, automatic scaling. More work up front, and a different way of operating afterward.
- Capacity follows demand, so you stop paying for idle hours
- Patching and backups move from your team’s calendar to the platform
- The application has to change, and so do the tests
- Worth it for individual workloads, rarely for the whole estate
The order that keeps a migration uneventful
Every estate is a different size and every change board works at its own pace, so we don’t commit to dates here. The order doesn’t change, and each phase ends with a document or a running system you can verify.
- 01Phase 1
Inventory and dependencies
We list everything that runs and map what talks to what. This is where the surprises appear: a license server nobody owns, a batch job writing to a shared folder no diagram mentions. You receive the map with the unknowns marked.
- 02Phase 2
Decide for each workload
Each workload gets one of four outcomes: move it as it is, rebuild it for the platform, replace it with a product, or switch it off. Switching off is the cheapest option and almost always underused. Every decision is written down with its reasoning.
- 03Phase 3
Build the landing zone
Before anything moves, we set up what it moves into: accounts, networks, identity and access, secrets handling and policy guardrails, all as code in your repositories. Every later workload inherits mistakes made here, so you review it before the first system moves.
- 04Phase 4
Move in waves
The first wave is low-risk but realistic: real dependencies, users who tolerate small issues. Later waves carry the systems people would notice at once. Each wave has a rollback plan that has been carried out, not just written, and is reviewed before it closes.
- 05Phase 5
Right-size and hand over
Sizes are adjusted to how workloads actually behave in the cloud, not to hardware bought years ago. Then dashboards, alerts, runbooks and the on-call procedure go to whoever will operate the estate, together with the decision record.
Rare releases are the risky ones
Deploying often is safer than deploying rarely. If a release contains one change, a problem can be traced in minutes. With three months of changes in one release, finding the cause means testing them one by one. The release window meant to reduce risk is what concentrates it, and small improvements get skipped because shipping them costs as much effort as anything else.
A pipeline alone won’t fix that. If the engineer who wrote a change can’t see it running, can’t read its logs without a ticket, and never gets the alert, automation only makes the same handover faster. What changes behavior is feedback reaching the person who made the decision. We will tell you which of those conditions the tooling depends on, and which only you can change.
What you are left with
The test is whether an engineer in their second week can read the pipeline, recreate an environment and roll back a release without asking anyone for help.
A pipeline you can read
Build, test and deployment steps are defined in files next to the code, so anyone can see exactly what happens when a change is merged.
Infrastructure reviewed like code
Networks, clusters and databases are defined in Terraform or an equivalent and changed through pull requests. A firewall rule gets the same review as a code change.
Environments you can recreate
A test environment is built from the same definitions as production and deleted when it is done. Drift stops being a problem when no environment lives long enough to drift.
A rollback you have practiced
Rolling back is a tested path in the pipeline, not a paragraph in a document. Your engineers carry it out in a real environment before anyone needs it under pressure.
Security that belongs to the estate
| Area | What gets checked | Enforced by |
|---|---|---|
| Identity and access | Excess permissions, unused keys, admin group members | Permission boundaries and access reviews in code |
| Network boundaries | Open inbound rules, public subnets, exposed endpoints | Deny-by-default rules, reviewed before merge |
| Secrets and keys | Keys in build scripts, rotation, backup access | A secrets vault and scanning in the pipeline |
| Pipeline guardrails | Infrastructure changes, container images, dependencies | Policy and scan checks before merge |
| Logging and detection | Log coverage, retention, who receives alerts | Alerts with named owners and runbooks |
| Account structure | Shared accounts, root account use, blast radius | Organization policies applied to new accounts |
Platforms and tools
The cloud platform is usually decided before we arrive, by an enterprise agreement or by where your engineers have experience, and your existing pipeline tools usually win too. We hold firmer opinions about the infrastructure code, because that is what you will maintain.
- AWS
- Microsoft Azure
- Google Cloud
- GitHub Actions
- Azure DevOps
- Terraform
- Docker
- Kubernetes
- Helm
- Microsoft Entra ID
- HashiCorp Vault
- Prometheus
- Grafana
- OpenTelemetry
What we get asked
You switch back. Every wave has a rollback plan that has been carried out in testing, and the old environment keeps running until the new one has worked reliably for an agreed period. The hard part is data created after the switch, so the plan says what happens to it and for how long switching back costs nothing.
Not sure which one you need?
Describe the problem in a paragraph and we will tell you which service applies.