Designing an End-to-End Customer Migration Runbook for a SaaS Platform Upgrade

Context

Enterprise customers in regulated industries were migrating from Archive 9 to Archive 10, a newer compliance-archiving platform. The upgrade required coordination between Training/Enablement, Customer Success, Provisioning, Data Services, and customer-side stakeholders. Training was deeply involved in the customer transition, but the process lacked a clear, repeatable runbook defining when Training entered the upgrade, what it needed to know beforehand, which discovery questions to ask, which requirements needed to reach Provisioning, when Data Services became involved, and what happened after go-live.

My Role

Coordinated with Provisioning, Data Services, Customer Success, and Training/Enablement to understand the full upgrade lifecycle and design a structured runbook the Training Team could follow end to end.

Business analysis angle

The runbook was built around a set of core BA disciplines applied to a live platform migration:

• Current-state analysis — understanding the existing upgrade process and where Training touched other teams
• Stakeholder analysis — identifying responsibilities, dependencies, and handoffs
• Process mapping — the customer migration journey from preparation through adoption
• Requirements elicitation — standardized discovery questions to surface workflow and configuration needs
• Requirements translation — converting customer business needs into actionable configuration requirements
• Dependency management — sequencing configuration, ingestion, migration, training, and go-live
• Process standardization — converting inconsistent, tribal practices into a repeatable runbook
• Validation — confirming implemented workflows met operational and compliance requirements
• Adoption — staying engaged post-implementation so migration translated into real usage

Customer discovery

Discovery was never just "what training do you need?" Training was gathering business and functional requirements that could affect downstream configuration — understanding how the customer's business actually operated, for example:

• How are communications reviewed today, and by whom?
• What groups and review permissions exist within the organization?
• Are shared mailboxes or classification tags required?
• Which workflows are compliance-sensitive, and which need to exist in the new platform?
• What differences from the old platform could affect the customer's workflow?

Requirements translation

Requirements surfaced in discovery — review groups, permissions, classification needs — had to reach Provisioning before new data began flowing into the platform, illustrating a clear chain: business need → requirement → technical configuration → customer workflow.

Workflow implementation and adoption

Once configuration was complete, the work didn't stop at explaining features. It included helping customers implement workflows that actually supported their operational and compliance requirements, then staying engaged through recurring enablement sessions so technical migration turned into effective, adopted usage — the point at which the customer realizes time to value.

Outcomes

• —Created a repeatable migration runbook for the Training Team
• —Standardized customer discovery across upgrade engagements
• —Clarified handoffs between Training, Customer Success, Provisioning, and Data Services
• —Connected customer business requirements to downstream system configuration
• —Improved consistency in how Training supported platform upgrades
• —Expanded Training's role beyond feature education toward workflow implementation and adoption
• —Improved visibility into upgrade dependencies