Support a clean handoff from project team to ongoing support, including the BA-to-Admin transition point
Section 1
The Phase Everyone Under-Teaches
Go-live is the moment a new system or process is officially launched and becomes operational: the actual launch of the application into the production environment. It is the moment every previous module has been building toward, and, oddly, it is the phase most training programs skim. That is a mistake this course will not repeat, because a large share of a project's actual value is won or lost after the build is done: in the readiness decision, the cutover window, the first fragile weeks live, and the long steady state that follows.
This module picks up where Modules 11 through 13 left off (configuration built, testing passed, training delivered) and closes out the project lifecycle. Different activities cluster before go-live, on go-live day, and after go-live; we will walk them in order: readiness, cutover, hypercare, and sustain. One boundary note: the retrospective and lessons-learned process that formally closes a project belongs to Module 17; this module hands off to it.
Section 2
Readiness: The Go/No-Go Decision
What It Is
A go/no-go decision determines whether a project is ready to move into cutover and go-live, or needs more preparation time. The core mechanic is a readiness checklist: a structured set of questions across multiple categories, each answered against defined criteria, and often scored (full marks for fully met, partial credit for partially met) against a minimum threshold to proceed.
Common checklist categories a BA should recognize, and can directly contribute to:
Change management communications completed and understood by affected users
User training completed
Stakeholder readiness and sign-off
System and integration testing completion
Data migration validation
User Acceptance Testing (UAT) sign-off
Production support readiness: the support team trained, staffed, and ready
Documented contingency and rollback plans
The BA's Role
The final go/no-go call is usually not the BA's to make: that typically sits with a project sponsor or steering committee. But BAs are frequently the ones who assemble the readiness evidence: confirming UAT sign-off status, confirming training completion, and surfacing unresolved issues and risks from earlier phases so decision-makers see a complete picture.
Here is the key teaching point, and it should feel like a reward for everything since Module 4: a go/no-go checklist is a condensed, final-gate version of everything the project has already been tracking. The RAID log, the RTM's test results, the training completion records: the checklist is a synthesis step, not a new activity. A BA who kept clean, current documentation all along assembles the readiness picture in an afternoon. A BA who did not spends a bad week reconstructing it. Your documentation habits were never bureaucracy; they were this moment, prepaid.
Pre-Go-Live Preparation
In the run-up to the decision and the launch, the BA's preparation workstreams:
Data migration and validation: assist with migrating and validating critical data from the legacy system into production (the Module 11 migration discipline, executed for real).
Finalize testing: coordinate and support the last UAT cycles, help end users test against real-life scenarios, and identify and document any remaining gaps.
Knowledge transfer: ensure system administrators and internal teams have received adequate knowledge transfer, and create or update user manuals (Module 13's deliverables, finalized).
Communication plan: establish support resources as agreed in the engagement documents; attend the go/no-go meeting to ensure alignment on go-live content and procedures; keep communication consistent with the existing project cadence; develop the plan for handling bugs and enhancement requests after go-live; and establish a clear handover process for post-go-live support.
Last-minute fixes: perform final end-to-end testing to verify the system operates as expected, and troubleshoot late-breaking issues as they surface.
Section 3
Cutover: Making the Switch
What Cutover Is
Cutover is the critical transition window when the old system or process is switched off and the new one goes live. It is carefully orchestrated to minimize disruption and protect data integrity: teams migrate and validate data, run final checks, and manage the precise sequence of steps that takes the solution into production.
The Cutover Plan
The cutover plan is the single source of truth for this window. Teams also call it an IT deployment plan, rollout plan, or runbook: same underlying concept. It is a detailed, sequenced list of every task required to bring the solution into production, with owners, timing, and dependencies, so nothing is left to "everyone already knows what to do." (Nobody does, at 6am on cutover day.)
Structural elements a BA should recognize, even when a dedicated cutover or release manager owns the document:
A high-level view: a visual summary of major cutover activities, their sequence, and dependencies: used to keep senior stakeholders aligned without dragging them through line items
A detailed task list: every cutover task with planned versus actual timing, the owning team and individual, status, and the system affected
A milestones view: just the major checkpoints, pulled from the detail, for status reporting
An action log: issues and follow-ups arising during cutover execution itself, tracked separately so the plan stays clean
A communications plan: who must be told what, and when, as cutover activities happen: often literally a filtered view of the same tracking sheet
A contact list: every person involved and their role, so there is zero ambiguity about who owns what during a high-pressure window
If this structure feels familiar, it should: it is the critical-path thinking of Module 5 and the RAID discipline of Module 10, compressed into one high-stakes weekend.
The Final Hours
In the last hours before cutover, the emphasis shifts from planning to confirmation: confirming responsibilities, finalizing checklists, and, above all, identifying a clear decision-maker empowered to pause or roll back if something goes wrong. Clear communication and escalation paths, the recurring BA and PM theme of this entire course, matter most at exactly this moment. A cutover with an ambiguous rollback authority is a cutover that will argue with itself mid-crisis.
Section 4
Go-Live Day
When the switch flips, the BA becomes the most visible person on the project:
Act as the initial point of contact for end users reporting issues
Log and categorize reported issues (the Module 12 severity discipline, live-fire), working closely with the development team on resolution as users interact with the system
Support users who have questions or hit problems, with patience: day one is when confidence is most fragile
Facilitate ad-hoc training or walkthrough sessions to address specific needs and challenges as they emerge
Many teams stand up a war room for go-live: a dedicated physical or virtual channel where the whole team monitors, triages, and communicates in real time. Alongside it, a set of structured sessions keeps the launch orderly: a go-live planning and communication session (key dates and milestones, communicated ahead), a go-live kickoff call, change-management-oriented training so users enter the new system equipped and confident, and scheduled post-go-live support windows. As a BA you can proactively suggest this session structure to clients: transition to production is a really big move, and offering a communication scaffold for it is exactly the partnership a good BA provides. (The same source material suggests an equivalent scaffold for UAT: kickoff and overview, end-to-end demo, test case walkthrough, a daily digest email, status touchpoints, drop-in defect triage, and a sign-off session: Module 12's process, expressed as a meeting cadence.)
Section 5
Hypercare: The First Few Weeks Live
What Hypercare Is
Hypercare is a short period of elevated, high-touch support immediately following a major go-live, designed to stabilize the new system quickly and catch problems before they spread. It typically lasts one to four weeks depending on rollout complexity, though large transformations sometimes plan longer.
The Four Phases
Planning and preparation (before go-live): review risks, update knowledge articles and documentation, train support staff on the new workflows, define escalation paths, and sometimes stand up temporary structures: a dedicated support queue, a war-room communication channel.
Go-live and rapid response: from the moment the system is live, closely monitor support channels and system performance, watch for volume spikes and signs users are struggling, and escalate technical issues through the predefined paths immediately.
Stabilization: once urgent issues are handled, shift focus to refining workflows, updating documentation based on early real-world lessons, and converting "what we learned in week one" into lasting process improvements.
Transition back to normal operations: case volumes and performance stabilize, temporary support structures wind down, staffing returns to normal, and the team runs a short retrospective before formally exiting hypercare.
Exit Criteria, Not Exit Dates
Define upfront what "stable" looks like: no critical open issues, key processes running smoothly, support service levels being met without extra help. Exit hypercare when the criteria are met, not when an arbitrary date arrives. An organization that exits on schedule rather than on evidence is simply moving its instability somewhere less visible.
The BA as Connective Tissue
Here is the BA-specific teaching point. During hypercare, the BA is the connective tissue between three groups: end users (confused, or hitting edge cases the requirements never anticipated), the support and admin team (who need to know whether something is a bug, a training gap, or a genuine new requirement), and the project team (possibly still closing out final items).
That three-way triage question, "is this what we asked for and someone doesn't understand it, or is this actually not what we asked for?", is answered by exactly the artifacts you have built all course: clear requirements, clear acceptance criteria, clear process maps. Your documentation habits from earlier phases directly determine how fast hypercare issues get triaged. A bug goes to the developers (Module 12's logging discipline). A training gap goes to enablement (Module 13's follow-up structures). A new requirement goes to the backlog (Module 4's craft, and Module 12's issue-versus-enhancement line, which will be tested daily during hypercare).
Section 6
Transition: Handing Off Cleanly
As hypercare winds down, the project formally transitions to whoever owns the solution ongoing. The BA's checklist:
Handover to support teams: transition ongoing maintenance and support activities to the appropriate individuals, and ensure support teams have access to training and support documentation.
Feedback handling: document informal end-user feedback; schedule retrospectives and feedback sessions with the project team promptly; ensure issues and concerns are addressed; and take time to personally reflect on what went well and what could have improved. (The formal lessons-learned process itself is Module 17's territory.)
Documentation updates: bring the solution design and other documents up to date with the final, as-built solution; update test case records; document work done on bug fixes and enhancements; update training materials based on feedback and newly discovered scenarios; and record all identified enhancements for future phases.
Training sessions: conduct post-go-live training as needed so the client is genuinely ready for sustained use.
Notice what a clean handoff actually is: the final, disciplined update of every artifact this course has taught you to keep. Documentation that dies at go-live was never documentation; it was project theater. The handoff is where it proves itself as the operating manual for whoever comes next.
Section 7
Sustain: Life After Launch
Once hypercare ends, the solution enters ongoing, steady-state operation: the sustain phase. It is the least glamorous and most overlooked part of the lifecycle, and a substantial share of the project's actual value is realized here, not at go-live itself. The core BA-relevant activities:
Backlog hygiene. Ongoing requests, incidents, and enhancement ideas keep arriving from business stakeholders. Triage them into clearly defined, actionable work items: the same discipline used during the original project, now applied to a live system. (An unmanaged post-launch backlog quietly becomes next year's "our system doesn't work" complaint.)
Adoption tracking. Monitor whether people actually use the new system as intended. Useful signals: active user counts and frequency of use, feature utilization rates, workflow completion rates, and adoption of the new process compared with the old one it replaced. This is Module 1's benchmarking promise redeemed: the before-and-after numbers that prove the project's value, and Module 9's reporting skills are how you surface them.
Documentation maintenance. Keep process documentation, configuration records, and operational runbooks current as the system evolves. This is what lets future changes (and future BAs and admins) work from truth rather than institutional memory.
Continuous improvement. Use adoption data and accumulated user feedback to identify friction points and propose refinements: essentially running smaller versions of the discovery and requirements cycle from Modules 3 through 5, against a live system instead of a greenfield project. The lifecycle, it turns out, is a loop.
The BA-to-Admin Bridge, Made Concrete
Sustain is where this course's BA-to-Admin bridge (Module 8) stops being a metaphor. A BA who has been closely involved through go-live and hypercare is often ideally positioned either to transition into an ongoing admin or support role for the solution they helped build, or to hand off cleanly to whoever will own it. Every sustain activity above maps directly onto Module 8's five admin responsibilities: backlog hygiene is product management, adoption tracking is actionable analytics, documentation maintenance is the data dictionary discipline, and continuous improvement is user observation feeding the release rhythm. For students of this course aiming at that first Salesforce job: the sustain phase of someone else's project is a very common front door.
Recap
Key Takeaways
Go-live is a decision, then a window, then a season: the go/no-go gate, the cutover, hypercare, and sustain each have their own disciplines.
The go/no-go checklist synthesizes evidence the project already holds (UAT sign-off, training completion, migration validation, rollback plans): BAs assemble that picture, and clean documentation makes it an afternoon's work instead of a scramble.
The cutover plan (runbook) sequences every task with owners, timing, and dependencies, supported by a high-level view, milestones, an action log, a communications plan, and a contact list: and the final hours are about confirmed responsibilities and a clearly empowered pause/rollback decision-maker.
On go-live day the BA is the front door: first contact, issue logging and categorization, user support, and ad-hoc training, often coordinated through a war room.
Hypercare runs in four phases (prepare, rapid response, stabilize, transition out) and ends on exit criteria, not dates. The BA triages the eternal question: bug, training gap, or new requirement: using the requirements and criteria written months earlier.
Transition is the disciplined final update and handover of every project artifact; sustain is backlog hygiene, adoption tracking, documentation maintenance, and continuous improvement: discovery skills pointed at a live system.
Sustain is where the BA-to-Admin bridge becomes a career path, and where the quality of every earlier phase's documentation is finally, fully cashed.
📝
Knowledge Check
8 questions. Answer at your own pace, then check the explanation for each.
Question 1 of 8
Who typically makes the final go/no-go call, and what is the BA's usual role in it?
Correct answer: B. Decision authority sits with the sponsor or steering committee; the BA's power is the completeness of the evidence.
Question 2 of 8
A go/no-go readiness checklist is best understood as:
Correct answer: B. It is a synthesis step, not a new activity: the payoff of clean documentation all along.
Question 3 of 8
Which of the following belongs in a cutover plan?
Correct answer: D. All are standard runbook elements, alongside the high-level view, action log, and communications plan.
Question 4 of 8
In the final hours before cutover, the single most important clarity to establish is:
Correct answer: B. An empowered pause/rollback decision-maker is the difference between a managed incident and a mid-crisis argument.
Question 5 of 8
Hypercare should end when:
Correct answer: C. Exit on evidence, not on calendar.
Question 6 of 8
During hypercare, a user reports that "the system is broken" because a screen does not show a field they expected. The BA's triage question is:
Correct answer: B. The three-way triage is the BA's hypercare job, and requirements documentation is what answers it quickly.
Question 7 of 8
Which of the following is NOT one of the sustain phase's core BA-relevant activities?
Correct answer: D. Contracts are settled; sustain is backlog, adoption, documentation, and continuous improvement.
Question 8 of 8
True or False: The sustain phase is where a BA who supported the project through go-live is often well positioned to transition into an ongoing admin/support role, making it a concrete BA-to-Admin bridge point.
Correct answer: True. Sustain activities map directly onto the admin's five core responsibilities, making it a natural career doorway.
🎉
Module 14 complete
Nice work. Review any question again using the menu (top right), or move on.