One month before go-live: where you should be, and what your vendor’s project manager should be doing
One month before go-live is the most revealing point in any system change. If the build is finished, the last month is calm: people are trained on the system they will actually use, and changes are kept to a minimum. If it is not, the last month becomes a race, and training happens on a system that is still changing underneath it. I have seen both, from the firm’s side and the vendor’s.
Download the one-month countdown checklist (Word) Download the go or no-go decision sheet (Word)
Where you should be, one month out
- User acceptance testing complete and signed off, with every defect fixed and retested, or accepted in writing with a workaround and a date.
- Trial migrations complete and validated: accounts reconciled matter by matter and signed off by the COFA, custom data and documents checked by the people who own the matters, and the final migration timetable rehearsed.
- Every case type and workflow tested and working, end to end, on both new matters and migrated matters part way through a process, with precedents generating correctly from the migrated data.
- Client and matter inception, new and improved: enquiry, conflict search, identity and AML checks, engagement letter, matter risk assessment and opening, tested as one process rather than a set of screens.
- Reviewed against your risk management: the configuration checked against your risk register and policies by the COLP and COFA, including client account controls, key dates, supervision and file reviews, permissions and ethical walls, audit trails and the breach register.
- Integrations working: the accounts package, email and Outlook, e-signature, searches, payments and anything else the firm relies on, tested with real scenarios.
- Reports validated: the reports partners, the accounts team and compliance officers use every week produce figures they recognise.
- Users and security ready: every user set up with the right role, multi-factor authentication on, and no accounts for people who have left.
- The cut-over plan written: the timetable, written go or no-go criteria, a fallback if it goes wrong, and who supports whom in the first weeks.
The last month is for training
End-user training belongs in the final month, on the system people will be working with on day one: the real configuration, the real precedents and workflows, and ideally their own migrated matters. Training on a demonstration system, or on a build that is still changing, teaches people a system that will not exist.
- Train by role, using the tasks each person actually does.
- Train close enough to go-live that people remember it, but not so close that there is no time to practise.
- Have super-users in each team who know the system well and can help on the floor from day one.
Any changes in this month should be very minimal: fixes to defects, and nothing else. Every other request goes on a list for after go-live. A change freeze is not bureaucracy; it is what keeps the training true.
What your vendor's project manager should be doing
- Running the cut-over plan to a detailed timetable, with named people on both sides.
- Scheduling the final migration and making sure the outgoing system's data extract will arrive on time.
- Holding the change freeze, with any exception agreed by both sides and its risk understood.
- Closing the issue log, reviewing it with the firm's project manager at least weekly, and daily in the last week.
- Coordinating training so that trainers, environments and the training data match the live configuration.
- Preparing go-live support: extra support in the first weeks, people on site or on call, a clear escalation route, and help with the first bills, the first month-end and the first bank reconciliation.
- Chairing the go or no-go decision against the written criteria (our go or no-go decision sheet sets them out, with open issues, conditions, a fallback trigger and sign-off), and reporting status honestly. A plan that is green every week until the last one was never green.
Warning signs at one month out
- User acceptance testing is still in progress.
- Some workflows or case types are "nearly done".
- The accounts have not been reconciled and signed off after a trial migration.
- New requirements are still being added.
- Training is planned on a demonstration system.
- There are no written go or no-go criteria.
If several of these are true, moving the date is almost always cheaper than a difficult go-live. Plan for that possibility early: if the old system's contract ends on a fixed date, leave enough time in the notice period for the project to slip without a crisis.
The one-month countdown checklist turns all of this into a week-by-week list, from the readiness checkpoint to the first month-end, with space for owners and dates.
We act as the firm's project manager or work alongside it: setting the readiness checkpoint, managing the vendor through the last month, and making sure the decision to go live is made on evidence, independently of any vendor.
Official sources
Check the detail for yourself at the source. Rules and guidance change, so always use the current version.
- SRA Accounts Rules: Client money, reconciliations (rule 8.3), residual balances and the accountant’s report.
- SRA Code of Conduct for Firms: Systems and controls, risk management, supervision and compliance officers.
- SRA: responsibilities of COLPs and COFAs: What compliance officers are responsible for, breach records and reporting.
- ICO guidance for organisations: UK GDPR guidance, including the right to erasure.
Where does your firm stand?
Our free practice management review shows how much of your current system you really use and, if you are thinking of moving, builds an independent requirements specification that takes your reasons into account. Nothing is sent to us.
Start the free review Talk to us