Go-live checklist for large-scale IT projects

TL;DR

• You cannot go live based on a calendar date. You reach a point where you can sign off that the solution is sufficiently complete, robust and low-risk.
• Define these points upfront, ensure they can be objectively verified and have a third party validate each point.
• Practise your cutover and rollback procedure in a non-production environment and decide in advance who has authority to execute the plan and when.
• Consider data, performance, security, user enablement and continuity of service. Passing development sprints alone is not enough.
• Agree a period of hypercare, the level of resourcing required and the conditions under which you will step back from that activity.

Table of Contents

• What go-live readiness means
• The go-live checklist at a glance
• Set go/no-go criteria before you need them
• Integrations and infrastructure
• Data migration readiness
• Performance and security
• People, training and support
• Build the cutover plan
• Plan rollback before you need it
• Hypercare after launch
• Where PODTECH fits
• Our perspective
• FAQ
• Sources

What go-live readiness means

Once a project reaches a certain maturity, there comes a time when you need to formally assess whether the system is ready to transition to a live state. Microsoft recommend that the team reaches this conclusion through a series of checks. That principle applies well beyond ERP implementations.

Importantly, go-live readiness should result in a decision. A checklist alone does not guarantee that the transition will occur without adverse consequences. What it should do is provide enough evidence for senior leaders to make an informed judgement about the state of the project, the residual risks and how those risks will be addressed if something fails.

Many of our customers operate mission-critical environments, so the consequences of a failed cutover are material. In many cases, the impact extends beyond the software platform itself. For that reason, we place significant emphasis on both executing and recovering from cutover in the checklist.

The go-live checklist at a glance

This is the starting point for developing your own. We elaborate on each area below.

You will note significant similarity to the areas outlined by Microsoft. In addition, the company requires that all testing activities are completed to their defined exit criteria and approved by key business parties.

Set go/no-go criteria before you need them

If you do not pre-determine the factors that must be met to proceed with go-live, you risk creating them ad hoc in response to external pressures, such as a desired launch window.

The M3 Playbook published by the US Government's General Services Administration provides a useful benchmark. The programme develops go/no-go criteria across the breadth of the transformation, from programme and system readiness through to workforce and operations. It defines the outputs required to signify a fit-for-purpose cutover, the actions to be taken in the event of a no-go or rollback, and the reporting of findings to executives for a recorded decision.

Similarly, the checklist used by the USDA WIC program sets out discrete criteria to satisfy before proceeding. These include completion of a defined suite of tests with defect counts by severity, a list of open issues and workarounds, completion of user training and site preparation, data migration against a specified baseline, performance and scalability testing, confirmation from key stakeholders, agreement of escalation and communications processes, and a contingency plan including any maximum period that the go-live decision may remain pending.

Criteria that work

Categorise your go-live checklist into the following five areas and assign an individual accountable for each:

1. Technology - Solution fit for purpose, defects identified and assessed against severity, release candidate achieved.
2. Data - Full volume trial completed, reconciliation approach determined, signed off by the data owner.
3. Commercial - End users and support staff trained and aware, temporary mitigations identified where needed.
4. Operations - Monitoring deployed, on-call roster confirmed, external parties notified.
5. Change - Change authorised, go-live freeze period identified, communications prepared.

You should then identify any showstoppers to release and explicitly state which individual or individuals can override them. Saying there must be no significant open faults is less robust than requiring, for example, no open Level 1 faults, no more than a defined number of Level 2 faults with known compensating actions, and only the Executive Sponsor able to lift those conditions.

Other interfaces and dependencies

Especially when working on a core function within a facility, the solution will likely sit alongside and interact with Building Management, Electrical and Telecoms systems. Each will have an associated account holder and planned maintenance window.

Per interface, ensure:

• End-to-end testing has taken place in a live-like setting, going beyond injecting fake data.
• Timing and capacity requirements have been met.
• There is a known counterpart contact in position during the transfer.
• Third-party providers are coordinated around the target date, including network operators and service providers.

Where applicable, clarity on terminology can also prove valuable. A Building Management System, or BMS, regulates and reports on life-support equipment in the facility and will frequently provide the data feed to be ingested by the solution. Ensure that the relevant tags, events and scan rates have all been fully verified ahead of transfer.

Similarly, if the Monitoring team has not been embedded in the programme from the outset, interfaces and data feeds often come to light too close to transfer. We discuss this in more detail in our article on involving Monitoring early in Data Centre Mobilisations. If you are migrating SCADA and other field systems to the cloud, our SCADA to Cloud Migration Guide assumes telemetry as its starting point.

Migrating data

As mentioned above, data is typically the key success or failure factor in any transfer. As a minimum, Microsoft advises that the data transfer should be run multiple times prior to go-live, with the overall methodology, process and any anomalies or concerns resolved. Each transfer run should also be executed and signed off.

Key considerations for the data transfer are therefore:

• Run a full-scale simulation of the transfer. A smaller subset may demonstrate feasibility, but only a full-volume run reveals whether the operation can be completed within the allocated timeframe.
• Establish and agree reconciliation levels such as record counts, summary balances, specific fields and ownership of variance resolution.
• Receive formal sign-off from the relevant party on completion.
• Plan disposition of the existing data and the period for which it remains accessible after transfer.

Our Database Migration Blueprints contain further best practice where large numbers of databases are being moved. If migrating from a legacy system, you will also need an additional layer of assurance that all known unknowns have been discovered and either retained or explicitly dropped. See migrating from Legacy Systems.

Performance and information security

Performance

Use representative production figures to stress the solution. You will want to benchmark the output of these runs against pre-defined KPIs, as discussed by Enov8. In some environments, peak demand may correspond with a high volume of simultaneous alarms, such as a loss of cooling. If you have not tested your system against that scenario, you have not sufficiently tested it.

Information Security

The information security checklist is relatively straightforward:

• Ensure appropriate handling of live accounts.
• Deprecate and update any commonly used or widely known login details.
• Remove any system-level logins.
• Confirm RBAC is correctly applied to all relevant users, including third parties and support teams.

Naturally, you will then want to validate this. Our articles on verifying RBAC is functioning as expected and ensuring RBAC remains effective through periodic access reviews are a good starting point.

Supporting the customer

Finally, the system should be fit for the customer to operate from day one. If it raises a fault and the user does not know the appropriate action to take, the transfer has not been successful. Ensure sufficient proof exists to demonstrate that the customer and their support organisation are capable of responding to issues.

From the list of prerequisites for an effective operations function published by Microsoft, including monitoring, maintenance, handover, support teams and helpdesk with an ITSM tool, we would recommend taking this a stage further and requiring the customer's support team to undertake a suitably scaled demonstration of the required key functions.

If your team includes site-based roles such as Site Supervisor, HSE Officer or Facilities, ensure they are trained appropriately on their specific activities. Construction companies commonly train site personnel on their role in implementing new technology solutions, as described here: digital transformation in construction. The same principle extends to all site-based functions.

Ensure that:

• All functions have been trained to complete their activity on day one.
• Helpdesk has appropriate documentation, escalation routes and a record of known issues.
• Any known issues requiring workarounds are documented and readily available to the relevant function.
• You have suitable communications prepared for senior leadership and site-based users, including progress, actions required, what is changing, the timeline and how to contact help. See Project Management Formula.

Develop a Cutover Runbook

Your cutover runbook should detail the series of actions required to take the environment from its current state to the target state. As outlined in the GSA M3 Playbook on Cutover, this should span pre-cutover, cutover and post-cutover activities. It should also align with the wider communications and go-live plan, and account for post-cutover considerations including warranty and amendments to the decommissioning plan for sunset systems.

Key fields to include in the runbook are: action, responsible party, planned start time, duration, pre-conditions, guidance and confirmation. That last field is often omitted, but it is critical. You need a reliable way of knowing, perhaps even at 3am, whether you can proceed to the next step.

The SDLC best practice guidance on cutover and rollback rehearsal sets out the elements that the rehearsal plan should consider: impacted solutions, processes, information, interfaces, third parties, environments, people and locations, along with freezes, pre-conditions, sequence, timing, decision points, acceptance conditions and residual limitations.

An indicative flow would be:

1. Apply freeze to the current solution and impacted interfaces.
2. Complete final backup and establish a restore point.
3. Execute migration and verify against the pre-defined process.
4. Update interfaces and obtain sign-off from each interface owner.
5. Complete agreed smoke testing in production.
6. Receive formal go or rollback from the appointed individual based on pre-agreed conditions.
7. Notify stakeholders and commence hypercare.

You should carry out a minimum of one full dress rehearsal. Following each rehearsal, capture the achieved timescales, lessons learned and revisions required to the runbook.

Establish Rollback

Rollback should be considered a normal element of go-live and requires a suitably defined and tested process.

As discussed above, the rollback plan should detail the conditions for triggering the activity, the final decision point, the restore point, impact on data and transactions, third parties, communications, timescale and verification of the restored solution. By setting the final decision point beforehand, there is no need to assess at the last minute whether rollback remains feasible. It is also prudent to consider remedial actions in the event that rollback is not possible.

Additionally, ensure you:

• Test the process. A rollback procedure that has not been exercised in a lower environment is unlikely to succeed in production. See this example.
• Identify a single decision maker. The decision should be based on objective pre-set criteria, such as incident severity, rather than group feeling.

These triggers may be linked to quantifiable metrics, such as a reconciliation difference exceeding a given amount or inability to restore a particular interface within a specified timeframe. Once again, Project Management Formula cautions that a feeling is insufficient.

Go Live and beyond

Once you have successfully met your go-live conditions, the project does not cease. There will be a period of increased attention and resourcing to support the solution, commonly referred to as hypercare. This too should be planned, specifying its length, resource requirements, escalation routes and conditions for closure. Typically, this spans 2-4 weeks for material implementations.

Conditions for ending hypercare may include a reduced number of incidents, zero Severity 1 and 2 tickets, transition to standard support resourcing and amendment of the decommissioning plan. Failure to define these conditions will likely lead to the project continuing indefinitely.

The role of PODTECH

By incorporating key go-live checks throughout solution design and implementation, you place the project in a stronger position to meet these milestones. PODTECH develops bespoke enterprise digital platforms for critical asset management. With more than 250 implementations to date, we operate an SLA of 99.9% availability and have extensive experience delivering BMS and PMS integration, data centre monitoring, system upgrades and enterprise-wide digitalisation using our in-house resources and by augmenting client teams where required.

If you are approaching a go-live and would benefit from help developing readiness checks, cutover and rollback with domain experts, begin with one of our datacentre offerings or reach out through the PODTECH homepage.

Our take

You will seldom see a critical go-live fail on the day. Typically, it failed many months earlier: when works to interface with the facility, energy and IT infrastructure were deferred; when live operations only came on board once the solution was complete; or when rollback was documented but never practised.

As such, we prioritise telemetry and interfacing throughout our engagements. With more than 250 go-lives behind us, that experience also informs our approach to executing cutovers. In addition, our solutions are supported worldwide to 99.9% availability.

To senior stakeholders, we recommend asking delivery teams to provide their written go-live prerequisites, nominate a key sign-off individual and confirm when their most recent cutover and rollback rehearsal took place. From there, you should know whether you are in a strong position to proceed.

Harry

FAQ

What goes into a go-live checklist?

Any number of elements that your team needs to satisfactorily demonstrate in order to transition to a live environment. These may include testing, data, interfaces, information security, user enablement, live operations, cutover and rollback. Crucially, you should be able to provide proof against each element.

What is required to trigger a go-live?

A responsible person, typically an executive, should formally approve the transition based on completion of a set of prerequisites. For example, the GSA M3 Playbook sets out a go/no-go meeting for senior management and the resulting decision, including any outstanding actions.

How does a cutover compare to a go-live checklist?

The cutover runbook provides the detailed instructions on how to execute the transition. As well as listing the individual activities, it should define sequencing, responsibility, duration, notifications, key decisions and rollback. Pre-, during- and post-activities all form part of this document.

How long will I need to run hypercare?

Depending on scale, expect 2-4 weeks. Determine this period, the level of resource and the conditions to conclude hypercare ahead of go-live, then close it once those conditions are satisfied.

References

• Ensure your implementation is fit-for-go-live with this checklist (Microsoft Learn)
• Key Task 4.16: Go/No-Go (M3 Playbook, GSA)
• Key Task 4.17: Cutover (M3 Playbook, GSA)
• WIC Go/No-Go Decision Checklist (Food and Nutrition Service, USDA)
• Rehearsing Cutover and Rollback as part of the SDLC
• How to Deploy Your Model at Your Customers Site (SuperML)
• Deployment Planning (Project Management Formula)
• Go-live checklist (Enov8)

Further reading

• PODTECH Legacy Modernisation
• IT Operations Optimization Workflow: 2026 Guide
• Why should I invest in a Legacy System Assessment?
• Integrating with third-party APIs (PODTECH)