Choosing Software

A software rollout succeeds or fails in the six weeks around go-live, not in the demo everyone sat through months earlier. This guide covers the discipline that applies to any rollout, in any software category: choosing the right rollout shape, naming an owner, running a pilot that actually tells you something, freezing configuration before go-live, training people properly, sequencing internal comms, working go-live day off a runbook, and holding checkpoints afterward that you're actually willing to act on.

If you're rolling out a specific category, the domain guides go deeper on what to configure: the CRM implementation guide, the HR software implementation guide, the marketing automation implementation guide, and the PM software implementation guide. This one covers what sits underneath all four: the rollout mechanics that decide whether the software gets used at all.

Why software rollouts fail

The failure is almost never the software itself. The tool gets configured, the licences get paid for, and eight weeks later half the team is still working out of the old system, a spreadsheet, an inbox, a tool nobody officially retired, because the new one asked for more than it gave back. Go-live is a date on a calendar. Adoption is the actual deliverable, and the distance between them is where most rollout plans stop budgeting effort. That distance has a measurable cost.

Key Facts: software rollouts and adoption

Organizations with excellent change management practices meet or exceed project objectives 88% of the time, against just 13% for those with poor change management (Prosci, Best Practices in Change Management research, 2,600+ change practitioners).

Just 49% of employees say the reasons for a workplace change are clearly communicated to them, down 7 points from 2023 (Institute of Internal Communication, IC Index 2026, 5,000 UK workers at companies with 500 or more employees).

Organizations leave an average of 36% of their SaaS licences unused against recommended utilization levels (Zylo, 2026 SaaS Management Index).

Almost 94% of features in the average software product go untouched, while just 6% generate 80% of all clicks (Pendo, product benchmarking data, 2024).

Nobody decided the rollout shape on purpose. A big bang gets picked because it's simpler to schedule, not because the team can absorb it in one day, or a phased rollout drags on for a year because nobody set an end date for the last group.

There's no single owner. Split between IT, the vendor's onboarding contact, and whichever manager championed the purchase, a rollout has three people who each assume someone else is watching adoption. That's most of the gap between the 88% and the 13% above: the difference isn't the software, it's whether one person owned the change and had the authority to act on what the pilot showed.

Training was a single session, weeks before anyone needed it. A one-hour webinar in week one, then silence until go-live in week six, teaches nothing that survives contact with a real workload.

Comms explained the tool, not the reason for it. People get a login and a feature list. Nobody tells them what decision the tool improves, so a chunk of them quietly conclude it's a reporting exercise and route around it, the same gap the IC Index number above is measuring.

Nothing gets measured beyond who has a licence. Licences activated is not usage. Without a hard number for how deep people are using the tool, a rollout that quietly failed looks, on paper, identical to one that worked.

Decide the rollout shape, name an owner, and size the pilot

Most of the damage in a rollout is done before anyone touches configuration, by whoever assumes the shape is obvious. Make these calls on paper first.

Pick the rollout shape on purpose.

Shape	What happens	Best for	Main risk
Big bang	Everyone cuts over on one date	Small teams, one clear workflow, low switching cost	No safety net if something breaks; the whole org feels it at once
Phased	Groups cut over in a set sequence, each a checkpoint	Distinct teams, regions, or processes; anything that benefits from a working pattern before it scales	The long tail: the last group waits months and momentum fades
Parallel run	Old and new systems run side by side for a defined window	Finance, payroll, safety-critical work, anything where a data gap is unacceptable	The "temporary" old system becomes permanent without a hard cutover date

Name a single owner, not a committee. One person, named before kickoff, holds the authority to change configuration, extend a checkpoint, or pull the abort trigger. A steering committee can advise; it cannot own, because nobody in a group of six feels personally accountable for week four.

Keep a decision log from day one. A shared doc, dated entries: what was decided, who decided it, why. Six weeks in, half the friction in a rollout is people re-litigating a call that was already made for a reason nobody wrote down. If you still need buy-in from the people the log will bind, the guide to getting team buy-in on new software covers that groundwork.

Size the pilot group before you build anything. Three to eight people is the usual range: one strong advocate, one honest skeptic, one person new enough to have no muscle memory to unlearn. Run it two to four weeks against real work, not a sandbox, and log every workaround; any workaround that survives the pilot becomes policy. This differs from a pre-purchase software trial, which tests the tool. A rollout pilot tests whether your rollout plan is right, on a tool you've already bought.

Freeze configuration before go-live. Set a date, a week or two before rollout, after which no new field, workflow, or integration ships until the first checkpoint. Every "quick change" requested in week five of a six-week rollout resets the clock on whatever the pilot already validated.

Get the data ready, and don't dump in everything you have. Load the records people need on day one, cleaned and standardized, and archive the rest read-only rather than importing it wholesale. A system that opens onto a few hundred accurate records earns trust immediately. One that opens onto years of unknown-quality history teaches the team, on day one, that the data can't be trusted.

A step-by-step rollout plan

Phase 1: Run the pilot on real work

Push actual transactions, tickets, or records through the pilot group, not test data. Two to four weeks is enough to surface the workarounds that matter; longer than that and you're gathering opinions, not evidence.

Phase 2: Fix the configuration, then freeze it

Take the pilot's defect list, fix what's fixable in days, defer the rest to a named v2 date, and lock the config. This is also the point to confirm every workaround the pilot surfaced either got built in or got a written reason it didn't.

Phase 3: Load the starting dataset

Import the clean, minimal dataset agreed earlier. Test that the export path also works, before anyone is depending on the system, not after.

Phase 4: Train close to go-live, not weeks before it

Training that lands two weeks before anyone touches the tool is training people forget. Sequence it instead: a short session in the days right before go-live, tied to the actual workflow people run, followed by office hours in the first two weeks rather than a single class that's supposed to cover everything.

Phase 5: Sequence the internal comms

Three messages, not one. First, what's changing and why, sent by the owner with the decision the tool improves stated plainly. Second, what to expect during the rollout window: dates, who to ask, what "done" looks like. Third, a written working agreement: what gets logged and by whom, and what management commits to in return, killing the shadow spreadsheet, running the real number off the new system, never asking twice for the same figure. That reciprocal half decides whether adoption sticks.

Phase 6: Run go-live day off a runbook

Timing	Action	Owner
One week before	Confirm config freeze, data load, and access are all clean; send the second comms message	Rollout owner
Go-live morning	Access verified for every named user; support channel opened and staffed	IT or admin
Go-live midday	First real transaction logged by each pilot member, as a smoke test	Pilot lead
Go-live end of day	Log every issue raised; triage against the abort criteria set in Phase 7	Rollout owner
Day 2	Send the "what we fixed overnight" note; keep support hours staffed	Rollout owner

Phase 7: Write rollback and abort criteria before you need them

Decide, in writing, before go-live, what actually stops the rollout. Writing the trigger down in advance is what keeps a bad go-live day from turning into three more weeks of pushing through on hope.

Trigger	Response
Data loss or corruption affecting real records	Roll back immediately; restore from the pre-cutover backup
A critical workflow is fully broken, with no workaround	Pause the rollout; fix it before widening access further
A defined share of the pilot group independently flags the same blocker	Treat it as confirmed, not anecdotal; fix before the next wave
Minor friction, cosmetic bugs, or a preference for the old tool	Log it, don't abort; this resolves with training and time

If none of the triggers fire, the decision log from earlier becomes the record of what you chose not to roll back on, and why.

Phase	Owner	Duration	Output
1. Pilot on real work	Pilot lead	2 to 4 weeks	Defect and workaround list
2. Fix and freeze config	Admin or ops owner	Days	Locked configuration, v2 backlog
3. Load starting data	Ops owner	1 to 3 days	Clean dataset, tested export path
4. Train close to go-live	Rollout owner, admin	Days before go-live, plus 2 weeks of office hours	Trained users, logged questions
5. Sequence comms	Rollout owner	Ongoing from kickoff	Three messages sent, working agreement signed
6. Go-live day	Rollout owner, IT	1 day, plus day 2 follow-up	Runbook executed, issues triaged
7. Abort criteria set	Rollout owner	Written before go-live	Named triggers, named response

Hold the 30, 60, and 90-day checkpoints

Book all three on the calendar before go-live, while you still have everyone's attention.

Checkpoint	Question	Action if the answer is bad
Day 30	Is the core workflow happening in the new system, not the old one, for the pilot group and the first wave?	Fix the blocker before widening the rollout; don't add scope to compensate
Day 60	Has the old system stopped being anyone's real system of record?	Name the specific holdouts, ask why, and treat the answer as a config or training gap, not a discipline problem
Day 90	Would removing the old tool's access break anyone's actual workflow?	If yes, you haven't finished the rollout, whatever the calendar says; if no, set the retirement date now

Measure usage depth, then retire the old tool

Licences activated tells you what was purchased. It tells you nothing about whether anyone changed how they work, and that gap is exactly what the Pendo and Zylo numbers in the Key Facts box describe: features nobody touches, licences nobody uses, both invisible if the only number you track is seats provisioned.

Vanity metric	What it actually tells you	Measure this instead
Licences activated	Someone clicked accept once	Weekly active users completing the core workflow action
Logins	Doesn't mean the work moved into the tool	Records created or updated per week, in the new system specifically
Training attendance	Presence, not competence	Task completed without help, a set number of days after training
Support tickets closed	Could mean fewer users as easily as more competence	Share of the workflow still happening in the old tool or a spreadsheet, trending toward zero

Once that last row hits zero and stays there through a full cycle, the old tool isn't doing anything except costing money and offering an escape hatch. Retiring it well takes the same discipline as rolling out the new one:

Set a hard retirement date and put it on the calendar, not a vague "once everyone's comfortable." Comfortable never arrives on its own; a date forces the remaining gaps to surface.

Test the export one more time before you cut access. Confirm anyone who still needs historical records has them, in a format they can actually open, before the old system goes read-only or gets shut off.

Revoke access rather than letting licences lapse. An account that quietly stops being renewed is still a login somebody can use to open "just this once," and just this once is how a shadow spreadsheet becomes the real system again within a quarter.

Announce the retirement the same way you announced the rollout. A dated message, from the owner, stating plainly that the old tool is gone as of a specific day. Silence here just reopens the same ambiguity the rollout comms were supposed to close.

Decision framework: what to do next

If your rollout situation is...	Then do this
Fewer than 20 users, one clear workflow, low switching cost	Big bang; target 2 to 4 weeks from pilot to full go-live
Several distinct teams or regions with different processes	Phase it; prove the pattern with one group before the next
Finance, payroll, or anything where a data gap is unacceptable	Parallel run, with a named end date for the parallel window, not an open one
No one has been named the single owner yet	Stop, and name one before you schedule go-live
The pilot surfaced a hard blocker	Fix or formally defer it before widening the rollout; don't push forward on schedule alone
Adoption has stalled at the day 30 checkpoint	Treat it as a configuration problem first, a training problem second, and a discipline problem last
Two systems still disagree at day 60	The old tool isn't retired, it's just running unannounced; set the retirement date now

If you're weighing whether to buy at all before any of this applies, avoiding software buyer's remorse and the SaaS vendor evaluation scorecard sit earlier in the process than this guide does.

Pricing: what a rollout costs beyond licences

The number in the contract is the licence. The number that surprises people is everything else it takes to get the team actually using it.

Some vendors publish an onboarding fee; most don't. HubSpot charges a published one-time onboarding fee of $3,000 on Marketing Hub Professional and $7,000 on Marketing Hub Enterprise. Salesforce publishes its Premier Success Plan at 30% of net licence fees on top of the subscription. Plenty of vendors instead fold onboarding into a quote-only enterprise tier, so check the vendor's own pricing page rather than assuming a rate that applied to a different tool.

Implementation partners price by the day, not a fixed catalogue. No partner publishes a rate card, and day rates vary widely by region, by seniority and by how much of the configuration you keep in-house, so any single figure you find quoted online is someone else's deal rather than a market rate. Treat this as a line you cannot estimate from a distance: get three fixed-scope quotes, each priced against the same written scope and the same number of days, and budget from the spread rather than from one number.

The internal-time line is the one that gets skipped. Budget the named owner at roughly a day a week for the six to eight weeks around go-live, the pilot group at two to three hours a week during the pilot, and every other user at two hours for training plus lost production time while they learn the workflow. Keep a smaller, permanent slice of the owner's time after that: a system with no ongoing owner is how you end up back at the Zylo and Pendo numbers above.

For the fuller cost picture across the whole ownership life of the software, not just the rollout window, the software total cost of ownership guide walks through what to add up.

Frequently asked questions

What's the difference between a big bang and a phased rollout?

A big bang moves everyone to the new system on one date. A phased rollout moves defined groups in sequence, each a checkpoint before the next starts. Big bang works when the team is small and the workflow is uniform; phased works when teams differ enough that one group's pattern needs proving before it's forced on the next.

How big should a pilot group be?

Three to eight people, run for two to four weeks against real work rather than test data. Include one strong advocate, one honest skeptic, and one person new enough to have no old habits to unlearn. Fewer than three and the result reflects one person's opinion; more than eight and the group stops agreeing on what happened.

What should trigger an abort or rollback during a rollout?

Write the triggers down before go-live, not during a bad go-live day: a data-loss bug, a critical workflow that's fully broken, or a defined share of the pilot group independently flagging the same hard blocker. A written trigger set beforehand is what stops a rough day from turning into three more weeks of pushing through on hope.

How long should the old system run in parallel?

Only as long as it takes to prove the new system produces the same output, with a hard end date set before the window starts. An open-ended "just until everyone's comfortable" parallel run rarely closes on its own; something else always looks more urgent than switching off a system that still works.

What's the single most important thing to measure after go-live?

Whether the core workflow is actually happening inside the new system, not who has a licence and not how many people logged in. Track the share of the real workflow still running in the old tool or a spreadsheet, and watch it trend toward zero. Licences activated and login counts both look fine right up until the week someone discovers the real numbers still live somewhere else.

Get the boring middle right

The part of a rollout that gets planned in detail is usually the configuration. The part that decides whether it works is the unglamorous middle: one named owner, a pilot allowed to say no, a scope freeze before go-live, training close to when people will use it, and checkpoints at 30, 60, and 90 days that you're willing to act on.

None of that shows up in a demo, and none of it costs a licence fee. It's also the entire difference between the 88% and the 13% in the Key Facts box above.

About the author

Calvin D.

Head of Enterprise Solutions

Calvin D. is Head of Enterprise Solutions at Rework, with 5+ years and 40+ enterprise engagements spanning 20 to 500+ user deployments. Calvin helps Heads of Operations, IT Directors, and VPs connect CRM, workflow automation, and data into one stack that actually fits together. Readers get field-tested architecture decisions they can apply as their teams scale.

View full profile LinkedIn