From a project management perspective, the go-live runbook must be a living document updated hourly during the cutover weekend.
Our template includes a ‘Decision Gate’ at every 4-hour mark. If any critical metric (abandon rate, trunk errors, agent login failures) exceeds the threshold, the team must decide: continue, pause, or rollback. Without explicit decision gates, the team will push forward blindly even when things are failing.
The Architect flow deployment order matters during go-live.
Deploy the In-Queue flows first, then the Inbound Call flows. If you deploy the Inbound flow before the In-Queue flow is published, calls that reach the queue will have no comfort message or hold treatment. The caller hears dead silence while waiting.
Also deploy your common modules BEFORE any flow that references them.
Architect flows that call a common module will fail at runtime if the module isn’t published yet. I learned this the hard way when 100% of calls hit the error path for 10 minutes because I published the parent flow before the shared authentication module.
You know what would be nice? If the platform had a dependency graph that showed the correct deployment order.
But of course it doesn’t. So you get to manually trace every flow reference, build your own deployment DAG, and pray you didn’t miss a shared Data Table lookup that somebody added 6 months ago without telling anyone. Good times.
After go-live, run an analytics comparison immediately.
Query POST /api/v2/analytics/conversations/aggregates/query for the first 4 hours of production data and compare against your PureConnect baseline. If AHT is more than 15% higher or service level is more than 5% lower, escalate immediately. The first 4 hours of data will tell you if the migration succeeded or failed.
For the rollback plan, pre-export every GC configuration element via the API the night before go-live.
If rollback is needed, you must be able to restore the GC org to its pre-go-live state. Use the bulk export endpoints to dump queues, skills, users, and flow configurations into JSON files stored in version control. This is your ‘undo’ button.