Internal software is adopted when the people who use it were involved before it was built, when their old way of working is switched off on a known date, when a trained champion sits in each team, and when someone measures use weekly for the first 90 days and fixes what the numbers show. Rollouts fail after go-live because the new system runs beside the old one indefinitely, training happens once in the week before launch, and nobody owns adoption once the project team has moved on.
The system works. It passed testing, the steering group signed it off, the go-live went smoothly. Three months later, half the team is still using the spreadsheet, the data in the new system is incomplete because people enter it late, and the reports nobody trusts are the reports from the new system. Nothing technical went wrong. The rollout was treated as the end of the project rather than as the part of it that decides whether the money was wasted. This post is about running that part properly.
Why do rollouts fail after go-live?
- The old way still works. If the spreadsheet is still open and the email approval still gets a response, the new system is optional, and optional systems lose to habit.
- Users met the system at launch. Nobody from the team tested a prototype or saw a release. The first impression is formed under pressure, on a real task, and it is negative.
- Training was an event. One session, the week before go-live, covering everything. Two weeks later nobody remembers the parts they did not need that day.
- Nobody owns adoption. The project team is reassigned at go-live. Questions go to a help desk that does not know the process. Small frustrations become reasons to stop.
- The system asks for more than it gives. It needs data entered that the user never benefits from. Managers see dashboards; the people entering the data see extra work.
- Managers did not change what they ask for. If the weekly report is still requested in the old format, the team keeps producing it the old way.
- Early feedback went nowhere. Users reported problems in week one, nothing changed by week four, and they concluded the system was finished and wrong.
Each of these is a decision not taken, usually because adoption was never given a budget, an owner or a place in the plan. Why enterprise software projects fail shows how that gap fits with the others.
What does a rollout plan look like?
| Phase | Activity | Owner | Measure |
|---|---|---|---|
| Discovery and design | Real users test the prototype, their feedback changes the design, the champions are chosen | Project owner with the vendor's designer | Users from each affected team have seen the core journeys |
| Build | Champions attend release reviews, the retirement date for the old system is set and announced, managers agree what they will stop asking for | Project owner | Retirement date published, champions trained on each release |
| Four weeks before go-live | Role-based training in short sessions on real tasks, quick-reference guides, a pilot team working live | Adoption lead with champions | Pilot team completing daily work in the new system |
| Go-live | Floor-walking support, a visible issue list with fixes shipped daily, the old system set to read-only on the agreed date | Adoption lead, vendor on site or on call | Issues raised and closed per day, logins per user |
| Weeks 1 to 4 | Weekly adoption numbers reviewed, top three frictions fixed each week, drop-in clinics | Adoption lead, steering group | Active users, tasks completed in system, time to complete |
| Weeks 5 to 12 | Old system archived, process documents updated, second release planned from feedback, adoption handed to line managers | Project owner, line managers | Data completeness, reports used from the new system, support tickets falling |
The adoption lead is a role, not necessarily a new hire. It is usually the operations lead or a senior user, with 30 to 50 percent of their time for three months, and a line in the budget for it. Programs that do not fund this role do not have one.
How do champions and training work in practice?
A champion is one person per team, chosen because the team listens to them and because they are good at the job the system supports, not because they like technology. They see every release during the build, so they know why things are as they are. They are trained first and deeper. At go-live they are the first point of contact, sitting with their own team, and they bring the top frictions to the weekly review. For this they need time allocated, a say in what gets fixed, and recognition that it is part of their job. Champions who are volunteered without time become the most frustrated users of all.
Training that works is short, role-based and repeated. A warehouse supervisor needs forty minutes on the three screens they use, on a real order, two weeks before go-live and again the week after. Nobody needs the two-hour overview of the whole system. Quick-reference guides, one page per task, beat a manual nobody opens. Short screen recordings, made by the champion, are watched more than the vendor's videos. The workflow automation post describes shadow mode, where the system proposes and a person confirms, which is also the best training there is.
What do you do with the old system?
Set a date on which it becomes read-only, announce it during the build, and keep it. Running two systems in parallel for a transition period sounds safe and is the most reliable way to fail: the old one wins because it is familiar, and the data splits between the two. The honest version of parallel running is a pilot team working fully in the new system for two to four weeks before everyone else moves, not everyone working in both.
Keep the old data accessible, read-only, for as long as the records are needed. Migrate what the new system needs, archive the rest, and make sure the few people who need history know where to find it. Data migration from legacy systems covers what moves and how. For spreadsheets, the equivalent is to move the file to a read-only archive on the retirement date and to make the manager stop accepting it as a report.
Which metrics tell you adoption is real?
| Metric | What it tells you | Healthy by week 12 |
|---|---|---|
| Active users against expected users | Whether people are using it at all | Above 90 percent of the intended users weekly |
| Tasks completed in the system against total tasks | Whether work has moved or is still happening elsewhere | Above 90 percent of the process volume |
| Time from event to entry | Whether data is entered as work happens or backfilled later | Same day |
| Data completeness on key fields | Whether the system can be trusted for reporting | Above 95 percent |
| Reports produced from the new system | Whether managers have switched too | All regular reports |
| Support tickets per week | Whether the frictions are being fixed | Falling week on week after week two |
| Old system activity | Whether the retirement held | Zero |
Logins are the weakest of these. People log in to systems they do not use. Tasks completed and time to entry are the ones that show whether the work has moved. Build the measures into the system during the build, so the numbers are available from day one without a reporting project.
What should the first 90 days look like?
- Week one. Floor-walking support, every issue logged and visible, fixes shipped daily. The adoption lead is present and the vendor is reachable within the hour.
- Weeks two to four. Weekly review of the numbers and the issue list. The three frictions that affect most people get fixed each week. Drop-in clinics replace scheduled training.
- Weeks five to eight. The old system is archived. Managers run their meetings from the new reports. The champions meet to compare notes and feed the second release.
- Weeks nine to twelve. Adoption passes to line managers as part of normal supervision. The adoption lead returns to their job. The steering group reviews the metrics against the business case and approves the next release.
Adoption checklist
- Users from every affected team tested the prototype.
- A champion per team, with time allocated, has seen every release.
- The old system's read-only date is published and will be kept.
- Training is role-based, short, and repeated after go-live.
- An adoption lead is funded for 90 days.
- Active use, tasks completed and data completeness are measured weekly.
- Managers have agreed what they will stop asking for.
How 7L approaches this
7L International builds and supports custom software for established organizations from business hubs in New York, London and Athens. Founded during the Greek financial crisis, we have supported more than one hundred organizations across hospitality, healthcare, finance, fleets and smart buildings, and we have learned that a system is finished when people use it, not when it passes testing. Our projects include users from discovery onward, champions in every release review, a retirement date for whatever the system replaces, and a presence on the floor at go-live. The enterprise software development guide shows where rollout sits in the whole program, and enterprise software support and SLAs covers what happens after the first 90 days. If you have a system that went live and did not land, tell us what the numbers look like and we will help you work out why.
Frequently asked questions
How long does it take for staff to adopt a new internal system?
With a planned rollout, most teams complete their daily work in the new system within four weeks of go-live and the old system can be archived by week eight. Without one, partial adoption can persist for a year or more, with data split between old and new. The difference is a retirement date for the old way of working, champions in each team, and someone measuring use weekly.
Should we run the old and new systems in parallel?
Not for everyone. Run a pilot team fully in the new system for two to four weeks before the rest move, then make the old system read-only on a published date. Full parallel running lets the familiar system win and splits the data between the two, which is the most common way a technically successful rollout fails.
What makes a good champion?
Someone each team already listens to, who is good at the work the system supports, and who has time allocated to the role. They should see every release during the build so they understand the decisions, be trained first and deepest, and have a real say in what gets fixed after go-live. Enthusiasm for technology is not required and is sometimes a disadvantage.
How much should we budget for adoption and change management?
An adoption lead at 30 to 50 percent of their time for three months, champions at a few hours a week each from the build onward, short role-based training sessions, and vendor presence at go-live. For a departmental system this is typically 5 to 10 percent of the build cost. It is the best-returning line in the budget, because it decides whether the rest of the budget produced anything.
What if users say the new system is worse than the old one?
Take it seriously and measure it. Sometimes a specific task genuinely takes longer, and that is a design fix for the next release. More often the new system asks for data entry that the user does not benefit from, in which case show them what the data does for them, or stop asking for it. Fix the top three frictions every week for the first month and the complaints usually turn into requests.