Migrating WebShop Without a Big Bang: Blue-Green Cutover, Data, and Rollback

A green All Apps deployment is not yet a migration. As long as users, writes, and external systems still point to the VM Apps WebShop, the target is only an expensive rehearsal. Conversely, switching DNS as soon as three VMs display “Ready” turns a reversible exercise into a potential data incident.

This chapter therefore treats cutover as an application change, not a VM relocation. The design keeps webshop-prod-042 in the VM Apps organization, deploys a distinct WebShop in ns-webshop-prod, and moves traffic and write authority in controlled stages. It is an unexecuted design reconstruction: thresholds, commands, timings, RPO, and RTO must be decided and rehearsed in the customer’s environment.

TL;DR

• Keep the source operable until the end of an explicitly approved observation period; deletion is never a cutover step.
• Returning traffic is generally simple while both rails use a data authority that blue can resume against. After the first write committed only to the target data authority, rollback depends on a tested reverse data path.
• On Monday, assign one owner to every DNS, IPAM, AD, CMDB, backup, and database write, then rehearse the runbook outside production.

The WebShop blue-green contract

Blue is the existing VM Apps service: webshop-web-01, webshop-app-01, and webshop-db-01. Green is a new All Apps set with separate names and identities: webshop-web-aa-01, webshop-app-aa-01, and webshop-db-aa-01. Both rails may coexist, but only one should own public traffic and only one should accept authoritative writes at any given time.

Consumers must depend on webshop.corp.example or a VIP, never on a VM address that became contractual by accident. In All Apps, the organization → project → Namespace → VPC boundary changes identifiers and network boundaries. Preserving the source IP, MAC, or deployment identity must not be an assumption in the plan.

Three data strategies, three risk profiles

The running example uses two waves. First, the All Apps Web and Application tiers temporarily consume the legacy database. Next, a new database is built in All Apps and fed through replication. Modernizing to DSM would be a separate project: combining it with the automation-model change would multiply variables and weaken rollback.

The boundary is therefore not the first write request routed through green. While both rails write to webshop-db-01, there is still one authoritative history. The boundary is the transfer of write authority to webshop-db-aa-01: the first transaction committed only to the target database. A weighted canary may carry writes only while both rails use that same authoritative database; never split writes across two active databases.

Build green without creating collisions

The target deployment must be complete but non-public. It receives its own address, certificates, possible computer accounts, monitoring objects, and a CMDB CI marked pre-cutover. It is not yet a member of the public pool. That separation makes it possible to test the real service without silently adopting a source object.

Before switching, compare both rails across the dimensions that matter: application version, configuration, capacity, inbound and outbound flows, TLS chain, identity groups, backup, restore, logs, alerts, and Day-2 actions. Parity does not mean a bit-for-bit copy. A different VM Class or Storage Class is acceptable when the performance contract is met and the difference is recorded.

Testing must start from actual user networks. A transaction from the administrator’s workstation proves neither branch-office DNS, proxy traversal, firewall rules, nor IdP behavior. The minimum set includes /healthz, /readyz, authentication, a business transaction with a write, correlated logs, an alert, and an isolated restore. Before the data-authority transfer, that write test must use the still-authoritative legacy database or disposable data that is removed before final synchronization.

cutover_contract:
  application: webshop-prod
  source_deployment: webshop-prod-042
  target_namespace: ns-webshop-prod
  traffic_switch: load-balancer-weight
  data_strategy: postgresql-replication
  source_recoverable_until: business-acceptance-plus-14-days
  decision_authority: application-change-board
  evidence_status: design-reconstruction
  execution_status: not-performed

This contract does not provide a universal value. “14 days” is an example of readable governance, not a Broadcom recommendation. The customer must align it with backups, licensing, dual-run cost, and how long a late dependency might take to surface.

Where rollback changes character

While green is read-only or writes to the same data authority that blue can resume against, returning usually means restoring blue to 100% load-balancer weight or restoring the DNS record. After the first authoritative write committed only to the target data authority, the source and target histories can diverge. A safe return then requires freezing the target, identifying the delta, replicating it back or restoring through the planned method, and validating the business transaction on blue.

The change record can express the decision like this:

go_no_go:
  go_if:
    - source_and_target_health_green
    - replication_lag_within_approved_rpo
    - target_logs_alerts_and_backup_visible
    - reverse_data_path_rehearsed
    - application_data_network_and_rollback_owners_present
  stop_if:
    - unknown_critical_dependency
    - target_identity_failure
    - restore_evidence_missing
    - concurrent_external_writer_detected

Metrics must be quantified locally: error rate, p95 latency, replication lag, number of reconciled transactions, and maximum freeze duration. An adjective such as “low” lets neither the change authority decide nor the on-call engineer trigger a return consistently.

Execute an observable switch

A weighted load balancer is usually easier to control: add the target at zero weight, validate health checks, send a canary, and then increase traffic through approved stages. A write-capable canary is safe only while both rails use the same authoritative database; after authority moves to the target database, route every writer there. DNS remains valid when the architecture lacks that lever, provided TTL is reduced early enough and non-compliant caches are measured. Do not change DNS and the load balancer together; one routing variable makes diagnosis simpler.

The operational sequence is short on paper, but every step produces evidence:

1. announce the window and freeze configuration changes;
2. quiesce writes when required by the data method;
3. complete synchronization and reconcile business counts or checksums;
4. move a canary, then the approved traffic share;
5. run smoke tests from user networks;
6. observe errors, latency, authentication, and the business transaction;
7. record the exact time when the target becomes the sole write authority;
8. declare provisional success, never deletion authorization.

The switch also affects external systems. DNS/LB points to green, IPAM retains both allocations during warranty, AD keeps distinct accounts, the CMDB marks the target active and the source retiring, monitoring routes alerts to the target team, and backup still protects the source while return remains authorized. Each system has one writer and a change log.

After provisional acceptance, the VM Apps catalog item should reject new WebShop requests while retaining the Day-2 actions needed by the existing service and the return plan. Its message points to the All Apps product. This freeze prevents new debt without destroying the safety net.

Rollback and incidents to rehearse

The return sequence is: declare the incident, freeze target writes, measure the delta, execute the reverse path, move traffic back to the source, test the transaction, and realign external writers. Green is not destroyed during the incident; its events, disks, and logs are part of the evidence.

Evidence that closes the window

The window closes only after the observation period finishes, no target-attributed incident remains open, target backup is restorable, and the data owner accepts reconciliation. The source then becomes a candidate for the drain described at the end of the series; it is not deleted automatically.

Conclusion

Blue-green buys time and visibility, not a magical guarantee. Its value comes from separated identities, simultaneous observation of both rails, and a reversible data path. The important moment is not the DNS change; it is the first write committed only to the target data authority, because that turns return into a data operation.

The declarative service preparation is covered in the previous article on Cloud Templates and extensions. Once WebShop is fully stable in its All Apps Namespace, the next step captures that Namespace with App Stack Formation.

Official sources: Bimodal Consumption Design · All Apps multi-tenancy model.