Implementing a new WFM system — the migration nobody plans for
Introduction
There is a great deal of advice on choosing a WFM system and almost none on the far harder part: actually implementing one. Selection takes a few months and ends with a signature. Implementation reshapes how your whole operation plans, schedules and reports — and it’s where most of the value, and most of the pain, actually lives. This article is a practical guide to the phases that matter, and the one nobody budgets enough for.
Discovery: document how you actually plan
The first phase is unglamorous and decisive: write down how your operation really plans today — not the official version, the real one, including every spreadsheet hack and tribal rule. Vendors configure to what you tell them, and the gaps you don’t surface here become the “the system can’t do X” complaints six months later. Map your shrinkage categories, your scheduling rules and constraints, your skill groups, your service targets, and the quirks of how demand actually behaves. This is also the moment to decide what not to carry over — a migration is a rare chance to drop bad habits rather than automate them.
Data migration: the quiet make-or-break
A WFM system is only as good as the data you feed it, and migration is where projects silently go wrong. Historical volumes and AHT need to come across clean and correctly mapped, or every forecast the new tool produces will be subtly off and nobody will trust it. Agent records, skills, contracts and working-time rules have to be accurate or schedules will break in ways that take weeks to diagnose. Budget real time for cleansing and reconciling this data, and validate it against known numbers before you build anything on top — a forecast that can’t reproduce last month is a forecast no one will believe.
Configuration: encode your reality, not the default
Out of the box, every WFM system embeds assumptions — about how shrinkage is defined, how service level is calculated, how schedules are scored. If you accept the defaults without checking them against how you measure things, your new numbers won’t reconcile with your old ones and the operation will conclude the system is wrong. Pin down the definitions early: what counts as shrinkage, which intervals service level is measured over, how occupancy is derived. Getting these right is the difference between a tool the operation trusts and one it quietly works around.
The parallel run: the step everyone tries to skip
Here is the phase that gets squeezed whenever the timeline slips, and the one you must protect: running the new system alongside the old one for a few planning cycles, comparing the outputs, and chasing down every difference until you understand it. Sometimes the new system is right and the old one was wrong; sometimes the reverse; either way you learn something, and you build the confidence to trust the new tool with live schedules. Skip the parallel run to hit a go-live date and you cut over to a system nobody believes, which is how expensive WFM implementations end up abandoned in favour of the old spreadsheets. Treat the parallel run as non-negotiable.
Cutover and stabilisation: plan for a dip
Even a well-run implementation has a productivity dip at go-live as planners learn the new tool and iron out configuration snags. Plan for it: cut over in a quieter period rather than into peak, keep the old system readable (not live) for reference, and protect your planners’ time for the first few cycles. Line up vendor support for the weeks immediately after cutover, when the real-world edge cases surface, and keep a running list of fixes rather than trying to perfect everything before launch.
The part nobody budgets: change, not software
The biggest reason WFM implementations disappoint isn’t the software — it’s that they’re run as IT projects when they’re really change projects. A new system changes how schedules are built, how agents request leave and shift swaps, how team leaders see adherence, how the operation is held to account. If agents and team leaders aren’t brought along — trained, consulted, given a reason to care — adoption stalls and the expensive new platform becomes a glorified rota printer. Budget as much attention for the people change as for the technical build, name an owner for it, and you’ll get the value the business case promised. Skimp on it and you’ll have bought a Ferrari to sit in the garage.
Related: choosing a WFM system, questions to ask the vendor, and what a WFM system actually is.