WRKBIZAP Legacy API Server Migration Plan

Status: Planning Owner: Infrastructure Target: H2 2026 (aligned with June 2026 decommission wave) Related: ciriussvcs-vnet-dependencies.md

Current State

• VMs: WRKBIZAP25, WRKBIZAP26, WRKBIZAP27
• Location: Firewall subscription, RG DESKTOPSREBUILD, CiriusSvcsVNET (10.4.0.0/16)
• Role: Payer API servers routing Medicare external payer traffic
• Dependencies: ACTDIRAP04/05 (same VNet) for legacy AD authentication

Target State

VMs either migrated to vnet-prod (10.20.0.0/16) in prod subscription, or decommissioned entirely if payer workloads can be merged into the existing production app tier. CiriusSvcsVNET (and ASR replica) deleted.

Migration Strategy

Two options — decision required from Rory before work begins:

Option A: Lift and shift to vnet-prod

1. Identify all payer API endpoints (public IPs, DNS names, firewall rules)
2. Stand up new VMs (WRKBIZAP28/29/30) in vnet-prod / servers-subnet
3. Update DNS CNAMEs and/or Palo Alto DNAT rules to point to new IPs
4. Parallel-run old and new for 2-week validation window
5. Cut over payer traffic
6. Decommission WRKBIZAP25/26/27
7. Retire CiriusSvcsVNET after DC migration complete

Option B: Merge into existing production app tier

1. Audit whether existing production workloads already cover payer API functionality
2. If so, migrate data and cutover via DNS only — no new VMs
3. Decommission old WRKBIZAP* immediately
4. Retire CiriusSvcsVNET

Payer API Inventory (to be completed during discovery)

• [ ] Enumerate all payer endpoints (IP, port, TLS cert, auth method)
• [ ] Document SLA / contractual response-time requirements
• [ ] Identify payer-side IP allowlists (external systems referencing our IPs)
• [ ] Review BAA language for any IP-pinned clauses

DNS and Load Balancer Changes

• [ ] List all CNAMEs / A-records pointing at WRKBIZAP25/26/27
• [ ] List all external-facing Palo Alto DNAT rules in scope
• [ ] Define TTL reduction window (24h pre-cutover drop to 60s)
• [ ] Post-cutover TTL restoration schedule

Cutover Steps

1. Freeze change window — no CM during cutover
2. Drop DNS TTL 24h before cutover
3. Run payer smoke tests against new endpoints
4. Update DNS / firewall DNAT
5. Monitor payer callback success rate for 72h
6. Restore DNS TTL
7. Keep old VMs running but deallocated for 7-day rollback window
8. After 7 days with no rollback: destroy VMs, delete NICs, delete disks
9. Remove Palo Alto rules referencing 10.4.x.x source zone
10. Delete CiriusSvcsVNET peering, subnets, VNet
11. Disable ASR replication, delete CiriusSvcsVNET-asr

Rollback Plan

If payer traffic fails post-cutover:

1. Revert DNS / DNAT changes (old VMs still running)
2. Investigate before retrying
3. If root cause is network-level (firewall, NSG), fix and retry
4. If root cause is application-level, engage application owner

Risks and Mitigations

Risk	Mitigation
Payer external allowlists reference old public IPs	Coordinate IP change with payer-side in advance; use static public IP on new side
Legacy AD clients hardcoded to ACTDIRAP04/05	Scan for static DC references before ACTDIRAP04/05 retirement
ASR replication orphan	Disable replication before VNet delete
CM freeze conflict with other June decommission items	Schedule cutover in distinct maintenance window

Success Criteria

• [ ] Payer API traffic serving from new location with zero SLA miss
• [ ] ACTDIRAP04/05 retired with no client outages
• [ ] CiriusSvcsVNET and ASR replica deleted
• [ ] Palo Alto rules referencing 10.4.0.0/16 removed
• [ ] BAA / payer documentation updated to reflect new endpoints

Change Log

Date	Change	Author
2026-04-16	Initial migration plan	Kobe