Why planning is its own phase
The most expensive DevOps mistakes are not bugs. They are sound implementations of the wrong design: a cluster topology that fights your team structure, a migration sequence that creates a fortnight of dual running, a pipeline standard nobody asked for. A plan is cheap to change. A half-built platform is not.
The Plan phase takes the evidence from the assessment and produces two linked artefacts: a target architecture and a phased DevOps roadmap. The promise is simple. You see the whole thing, argue with it, and approve it before we touch anything.
What good looks like
A strong plan has these properties:
- Goal-linked: each phase ties to an outcome you care about, such as fewer incidents, faster releases, a compliance requirement or a migration deadline.
- Sequenced by dependency: identity and network foundations before workloads, observability before migration, not after.
- Reversible: every phase states how to roll back, and what that costs.
- Verifiable: acceptance criteria are concrete enough that you can check them yourself.
- Honest about risk: unknowns are listed, with how we intend to reduce them.
A plan that cannot be wrong is not a plan. It is a brochure.
The target architecture
We design the target state across the layers your assessment showed need attention. Typical sections:
- Accounts, subscriptions and landing zone: how environments are separated, who owns what, how guardrails are applied.
- Network and connectivity: address plan, segmentation, private connectivity, ingress and egress.
- Identity and secrets: role model, federation, short-lived credentials, secret storage and rotation.
- Delivery: source control flow, build, test, artefact storage, promotion between environments, approval gates.
- Runtime: Kubernetes (EKS, AKS or other), serverless or VMs, with reasons.
- Observability and operations: metrics, logs, traces, alerting, on-call, backup and recovery targets.
Diagrams are kept in text where possible (Mermaid or similar) so they live in your repository and change through review like everything else.
Recording decisions
Every significant choice is captured as a short architecture decision record. A useful one fits on a page:
ADR-004: Use GitOps for cluster deployments
Status: Proposed
Context: Deployments to three clusters are run by hand from laptops.
There is no record of what is deployed or why.
Decision: Declare cluster state in Git and reconcile with Argo CD.
Alternatives considered:
- Push-based deploys from CI: simpler, but credentials live in CI.
- Flux: viable; rejected only because the team already knows Argo CD.
Consequences: Rollback becomes a Git revert. Team must learn the
app-of-apps pattern. Drift is visible and corrected.
The “alternatives considered” section is the part reviewers value most. It shows that the design was weighed, not assumed. For the reasoning behind that example, see our GitOps with Argo CD on EKS tutorial and the GitOps service.
The phased roadmap
The roadmap translates the architecture into deliverable chunks. Here is an illustrative structure, not a prescription:
| Phase | Purpose | Key deliverables | Exit criteria |
|---|---|---|---|
| 1. Foundations | Safe base to build on | Account structure, state backend, identity model, baseline monitoring | Foundations reviewed and reproducible from code |
| 2. Delivery | Reliable path to production | Standard pipeline, artefact promotion, secret handling | A pilot service deploys end to end with rollback tested |
| 3. Platform | Run workloads consistently | Cluster build, ingress, policy, autoscaling | Pilot workload runs on the platform under load you define |
| 4. Migration | Move remaining services | Service-by-service cut-over plans | Each service has passed its cut-over checklist |
| 5. Hardening | Reduce operational risk | Alert tuning, backup restore test, runbooks | Restore and failover exercised and documented |
Real roadmaps differ. A team with healthy pipelines may skip phase 2. A compliance-led client may move hardening forward. What stays constant is that each phase has an owner, deliverables, exit criteria and a rollback note.
Sizing without false precision
We estimate in relative terms and state assumptions openly. Anything that depends on a third party, a procurement cycle or your team’s availability is flagged as a dependency rather than buried in a date. We do not promise outcomes that depend on factors we do not control.
Decisions and trade-offs we put in front of you
Planning is mostly decisions. Common ones:
- Managed Kubernetes or simpler compute: Kubernetes is powerful but carries operational weight. If a handful of services would run happily on a managed container service, we will say so. Our Kubernetes consulting page covers when it is worth it.
- Big-bang or incremental migration: incremental is usually safer and slower. Which fits depends on your tolerance for dual running.
- Build, buy or adopt open source for monitoring and delivery tooling, weighed against the skills your team has.
- Standardise now or later: premature standards frustrate teams, and none at all multiplies drift.
If you are moving workloads between clouds or from a data centre, the same discipline applies to the cloud migration plan.
What we need from you
- The assessment report, or equivalent access and documentation if you skipped that phase.
- Business context: product roadmap, launch dates, compliance and budget constraints.
- Reviewers: someone technical who will challenge the design, and a decision maker who can approve it.
- Availability for review sessions with the engineers who will run the result.
Decision points and approval
There are three gates. First, agreement on goals and constraints before design starts. Second, design review, where the architecture and decisions are challenged. Third, written approval of the roadmap, whole or phase by phase. After approval, the work moves to implementation. If you prefer to continue with a different provider, the plan travels with you.
How to verify the quality of a plan
Check that the plan answers these questions without hand-waving:
- What happens if phase two fails halfway?
- Who owns each deliverable after handover?
- Which assumptions, if wrong, would change the plan?
- How would an outsider confirm that each phase is done?
- Which decisions did we reject, and why?
If you want help scoping the plan, talk to us or review our engagement models.