Enterprise software go-live checklist

Go-live is the transition in which enterprise software such as an ERP, MES or quality management system moves out of the test environment and becomes the live system that runs the company's daily work. A successful go-live is not the work of a single day; it is the outcome of a project cycle that runs from scope definition to support handover.

This checklist summarises, phase by phase, the working approach the ORELSIS team follows on enterprise software projects such as OREL MRP, OREL QMS and OREL DMS. It is written so you can adapt it to whatever software you implement.

Project charter, scope and roles

The project charter is a short, approved document that states why the project exists, what it covers, who makes decisions and how success will be measured. Projects that start without a charter see scope grow constantly and decisions shift from person to person.

Steering committee and roles

The steering committee is the senior group that makes decisions on scope, budget and schedule. It meets regularly, hears the project manager's report and unblocks stalled decisions. Writing roles down answers in advance the question of who decides during go-live week.

R: responsible, A: accountable, C: consulted, I: informed. IT and the vendor team can also be tracked as separate columns; what matters is a single accountable party per row. Key users should be chosen from people who know the process best and can dedicate a meaningful share of their time to the project.

As-is and to-be process analysis

As-is analysis describes how work is done today; to-be design defines how it will be done with the new system. The goal is not to copy today's process into the software but to match the business need with the system's standard flow.

1. 1.Name the owner and key user for each process.
2. 2.Map the current flow, the forms, Excel files and approval steps in use.
3. 3.Note problems and improvement expectations inside the process.
4. 4.Demonstrate the software's standard flow live to key users.
5. 5.Draw the target flow and list each gap as a separate record.
6. 6.Choose a resolution for each gap: process change, configuration, report or development.
7. 7.Have process owners approve the to-be process documents.

Configuration, customisation and environments

Configuration adapts the software to the business need through its own settings (parameters, workflows, fields, report definitions). Customisation is development that changes the code. Customisation is sometimes necessary, but each one adds testing, maintenance and upgrade effort.

• First consider changing the process: does the standard flow meet the need?
• Then try configuration: is a parameter, field or workflow setting enough?
• If a report or integration can solve it, don't touch the core.
• Approve customisation only for a legal requirement or clear business value, and write down the reason.
• Define an owner, test scenario and documentation for every customisation.

Environments

At least three separate environments are recommended. Development is used for configuration and development, test for integration and acceptance testing, and production for daily work. Changes move between environments only through a logged and approved transport method.

Data migration plan

Data migration is the controlled transfer of master data and open balances from legacy systems into the new system. The data to migrate consists of master data such as items, BOMs and business partner records, and opening data such as open orders, stock and balances. Whether historical transactions move is decided separately.

1. 01
   Scope and mapping

   Define the objects to migrate, the source system and field mapping. Assign an owner to each object.

2. 02
   Extract

   Extract data from the source system with a repeatable method; don't rely on manual copying.

3. 03
   Cleanse

   Fix duplicates, missing fields and invalid values together with the source owner. Leave inactive records out of the migration.

4. 04
   Transform and load

   Convert data to the target format and load it into the test environment. List and fix records that fail.

5. 05
   Reconcile

   Compare record counts, stock quantities and balance totals with the source. Explain differences and have the owner approve them.

6. 06
   Rehearsal

   Rehearse the full migration end to end at least once, under conditions close to the real cutover sequence and duration.

Test phases

Testing is the work of proving that the system runs the target processes correctly. Entry and exit criteria for each test phase are written up front, so when a phase is finished is not up for debate.

Training plan

Training makes sure users can do their own work in the new system. An effective plan has two layers: key users are trained in depth first, then they and the project team train end users by role.

• Key user training: Configuration logic, process flow, common errors and how to resolve them. Starts alongside process design.
• End user training: By role, based on their own daily transactions and in the test environment. Delivered close to go-live.
• Manager briefing: Reports, approval steps and KPIs.
• Training materials: Short role-based user guides, step lists with screenshots and FAQs.
• Practice environment: A separate space where users can try things after training.

Training is only one part of change management. Tell users regularly throughout the project what will change, why and when. Managers visibly owning the new process, key users acting as the first point of contact in their departments and user feedback being handled visibly all directly affect adoption of the system.

Cutover plan and go/no-go decision

The cutover plan is a detailed work plan that lists every task to be done while the legacy system is closed and the new system opens, with time, owner and dependencies. The plan is tested with real durations during the rehearsal and includes rollback steps.

1. 01
   Change freeze

   After the set date, configuration and master data changes are made only with an exception approval.

2. 02
   Transaction close

   Open transactions in the legacy system are closed or listed; the last entry time is announced to all departments.

3. 03
   Final data migration

   Opening stock, balances and open documents are loaded into production and reconciled.

4. 04
   Smoke test

   Critical processes are tried in production with short scenarios: login, order, production entry, output and integration.

5. 05
   Go/no-go meeting

   The steering committee reviews the criteria one by one and records a go or rollback decision in writing.

6. 06
   Opening and announcement

   User access is opened and support channels and the contact list are announced.

Rollback plan

The rollback plan defines how, and up to which point, you return to the legacy system if a serious problem occurs during cutover. It covers until when the legacy system stays read-only and usable, how data entered during cutover is handled, who decides and how users are informed. Rollback steps should also be tried at least once during the rehearsal.

Hypercare

Hypercare is the period right after go-live in which the project team gives users intensive support. Issues are collected, prioritised and resolved quickly. Its duration is set up front based on the system's scope and critical events such as the first period close.

• Set up a support team reachable on site and remotely; key users are the first support tier.
• Collect all requests in one tracking tool; also log those that arrive by email and phone.
• Review open records in a short daily meeting.
• Turn recurring issues into training, documentation or configuration improvements.
• Run the first period close (month end, inventory) together with the project team.

Response times should be agreed jointly based on the contract and how critical the work is. The wording in the table is a starting framework.

Support handover and post go-live review

Hypercare ends when the agreed criteria are met and the system is handed over to the permanent support model. Handover is not a date but an acceptance process: open records, documents and responsibilities are delivered in writing.

The post go-live review looks at how far the project met its objectives and what lessons were learned. The business objectives written in the charter are measured again with live data; practices that worked well and those not to repeat are recorded for future projects.

Common mistakes

• Starting configuration before scope is frozen in writing.
• Assigning key users to the project without freeing them from daily work.
• Building many customisations to copy today's process as is.
• Leaving data cleansing to the weeks right before cutover.
• Having the project team run UAT and not getting process owners' sign-off.
• Estimating real cutover duration without a rehearsal.
• Scheduling go-live to overlap with month end or peak shipping.
• Leaving hypercare unplanned and losing requests across different channels.

Closing

A successful go-live depends less on the technical installation of the software than on decisions being made on time and in writing. Adapt this list at the start of your project, review it at the end of each phase and walk into the go/no-go meeting with criteria. That way go-live becomes a planned step, not a day of risk.