What to prepare before your new system goes live

Before setting a launch date, identify the tasks the new system must support. In the order-management example, staff must be able to create an order, a manager must be able to approve it, and the warehouse must receive the correct quantities to prepare. Individual screens opening normally is not enough if an order cannot complete that workflow.

Each department’s owner should confirm the test results relevant to its work. Technical staff verify the operating environment, connections and error monitoring; business owners verify the figures and processes. For unresolved issues, document the impact, the workaround and who has approved the proceeding. A lack of objections should not be treated as confirmation that every department is ready.

For example, an incorrectly colored label might be fixed later if it causes no misunderstanding. An error sending the wrong quantities to the warehouse, however, could prevent launch. These examples illustrate how to consider impact; they are not acceptance rules for every project. The decision-maker needs to understand the consequences of what remains unresolved.

Before approving launch, have the people who will use the system test important scenarios and record the expected results. Software acceptance: What should your business test? helps you prepare those checks, so the decision rests on verified business tasks rather than simply a report saying that testing is complete.

Readiness also depends on users: their accounts must work, permissions must match their roles, and workplace equipment must be usable. Staff should practice with a sample order and know whom to contact when they get stuck. Instructions that only describe screen buttons will do little to help when a customer changes a request or an order needs to be put on hold.

The cutover schedule should show the order of tasks, who performs and verifies each one, and when the next step may begin. In this example, the plan might start by stopping order updates in the old system, extracting the final data, loading it into the new system, reconciling it and notifying staff that they can begin. This is an illustrative sequence; the procedure must be checked against the actual systems.

Each milestone needs a clear meaning for the people involved. Does “data migrated” mean the technical team finished loading it, or that someone has checked order counts and outstanding balances? Does “ready for use” mean login access is enabled, or that new orders have been confirmed to reach the warehouse correctly? Clear completion conditions prevent one team from assuming the work is done while another is still waiting.

In particular, decide where transactions arising during the cutover will be recorded. If sales continue entering orders in the old system while data is being extracted, those later orders may not reach the new one. If entry is allowed in both systems, there must be a way to identify and reconcile records to avoid duplicates. Moving your data: What needs to be checked? explains the cutoff, handling of later updates and verification before use.

Choose the timing around business activity rather than assuming a weekend is suitable. Retailers may be busiest at weekends, while accounting teams may be unable to pause during a financial close. Reviewers and support staff must also be available in the chosen window. A quiet trading period can still lead to delays if nobody is available to approve the results.

Rehearse the whole process, not just the technical steps

Before the actual switch, test the plan in an appropriate environment or walk through each step together to uncover gaps. Owners need to know how long a task takes, whom they must wait for and how updates will be communicated. If the rehearsal shows that the data approver is only available after the warehouse shift begins, adjust the schedule or responsibilities before launch.

For a rollout by branch or user group, choose an initial group whose work is representative and that can receive close support. Before expanding, check what differs in the next group: equipment, approval processes or shared data. Phasing can limit the number of people affected, but it also increases coordination between the old and new ways of working during the transition.

The plan should specify when to stop, who decides and how business work will continue in the meantime. In the order example, if a new order does not reach the warehouse or final figures contain unexplained differences, the owner must know whether staff may keep entering orders. Departments should not each improvise their own response.

Distinguish three options: postponing before the switch starts, pausing to fix the new system, or returning to a prepared fallback. The choice depends on the problem, data already created and time remaining. Returning to the old system is not always straightforward, particularly after new transactions have been recorded.

Suppose staff have entered several orders in the new software before discovering a problem. Reopening the old system without those orders could cause the warehouse to miss them; re-entering them without reconciliation could lead to duplicate deliveries. A rollback plan must therefore explain how new data will be preserved, checked and transferred. Technical and business owners need to agree on the same process.

Allow time to carry out the fallback. If the decision is delayed until the cutover window has been used up, there may be too little time to restore service before the next shift. Define warning signs and a decision deadline using rehearsed timings, rather than waiting for the problem to become serious.

A backup supports the fallback only if the team can recover the correct data and return the system to a usable state. How to back up and recover business data explains what to confirm and how to test recovery before a backup is needed in a real incident.

After launch, check whether work is actually flowing: have orders reached the right department, are any stuck, and are users recording information manually? An error-free screen does not establish that the whole process is working. Business users and operations should check important transactions together, especially handoffs between departments.

In the early days, use one intake point and assign someone to triage issues before passing them to the right team. A missing order might be caused by permissions, unmigrated data or an unfamiliar filter. Treating every case as a software defect can send technical staff in the wrong direction. Reporting instructions should request enough detail, such as the action, an order reference suitable for sharing and the time of the issue, while keeping sensitive data out of broadly accessible chats.

Track remaining issues until they are resolved or an agreed alternative is in place. If orders are temporarily recorded manually, assign someone to reconcile and enter them afterward; otherwise the workaround can leave records missing. Repeated operating mistakes may also signal a need to improve instructions or the workflow, rather than simply answering each user separately.

Before ending transition support, confirm that operations has the accounts, instructions, contacts and open-issue list it needs. Agree who monitors alerts, who updates the software and which cases fall within the support scope. What does software maintenance actually cover? clarifies the work that continues after the system is in use.

Do not end the support period simply because its scheduled number of days has elapsed. Check the agreed conditions: important transactions have been verified, work-blocking issues have been resolved, and operations knows how to take over what remains. If those conditions are unmet, the owner needs to decide what else is required and how support will continue.

To prepare a rollout with Fenix, start with three things: the work that cannot be interrupted, the intended cutover date and the person authorized to approve each department’s readiness. These give both sides a basis for agreeing the schedule, start conditions and responses to problems around the realities of your operations.

Discuss your project with Fenix