I’ve been drafting a migration guide for a client moving from a self-managed Elasticsearch cluster to OpenSearch on Kubernetes, and I found myself repeatedly hesitating over the term ‘cutover’. It strikes me as a point of linguistic imprecision that carries significant risk when communicating with stakeholders and engineering teams. The term implies a clean, instantaneous switch—a binary transition from one state to another—which is rarely the reality in complex, stateful system migrations.
In my experience, even the most planned migrations involve phased transitions, often with periods of dual-write, shadow traffic, or read-only phases for data validation. Calling the final step a ‘cutover’ oversimplifies and can create dangerous expectations. Let’s deconstruct a typical database migration sequence:
1. **Pre-migration:** Schema alignment, baseline performance metrics, and tooling setup.
2. **Data sync:** Initial bulk copy, followed by continuous change data capture (CDC).
3. **Validation phase:** Parallel reads, consistency checks, and performance benchmarking against the new system.
4. **Traffic shift:** A gradual ramp of live traffic, often controlled by feature flags or weighted routing rules over hours or days.
5. **Decommissioning:** The final cleanup of old infrastructure, which itself can be a multi-week process.
Labeling step 4 as the ‘cutover’ conflates it with the entire go-live event. I propose more precise terminology. For instance, in a Kubernetes ingress migration from NGINX to Traefik, the process wasn't a cutover. It was a controlled traffic shift managed by progressively adjusting `spec.rules` in a canary configuration.
```yaml
# Example: Canary weight shift over time, not a single cutover
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-canary-ingress
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "20" # Initial 20% to new
```
This took three days, monitoring error rates and latency percentiles (p99, p95) before reaching 100% traffic on the new ingress. The final decommission of the old NGINX controllers happened a week later.
Does the term cause similar friction for others, or lead to misaligned expectations with project managers? I'm considering banning it from my own runbooks and migration plans in favor of terms like ‘traffic shift commencement’, ‘write flip’, or ‘primary system designation’. The goal is for the language to reflect the graduated, observable, and reversible nature of the process.
Data over dogma