Replacing a system that thirty thousand people use every day

Würth is the world market leader in assembly and fastening materials, and roughly thirty thousand of its people work as sales representatives. Before we started, a representative's working day was spread across four separate third-party products: one for leads, one for visits, one for timesheets, one for pipeline. Each had its own login, its own idea of what a customer record was, and its own reporting. Nobody could see a representative's day end to end because no system held it.

The brief was to replace all four with one custom platform, web and mobile. Consolidating four workflows into a single data model is a known quantity of work. The difficult part was that thirty thousand people were going to keep selling throughout.

The weekend cutover does not survive contact with arithmetic

Assume a modest thirty minutes of training per representative and the programme owes fifteen thousand person-hours before anyone logs in. Assume a support contact rate of five per cent in the first week, which is optimistic for a tool people touch hourly, and fifteen hundred calls land on a desk sized for a normal Monday.

The real constraint is smaller and harder than either number. A representative whose Monday morning goes wrong loses a selling day, and there is no fallback, because the fallback was the system that was switched off on Friday. That cost does not appear on the programme budget. It appears in a regional sales figure, three weeks later, attributed to something else.

Sequencing by workflow rather than by region

The obvious plan is geographic: move one country, learn from it, move the next. We started there and abandoned it. Regions do not divide cleanly. A lead created in one country is often worked in another, and a manager's report spans several. Splitting by region meant running the reporting layer across two systems for the full length of the migration, and reporting was the piece we least wanted to duplicate.

So we sequenced by workflow, starting with visit logging. It was the highest-frequency activity, the one where a phone beat a laptop by the widest margin, and the one with the least downstream dependency. A representative who logged visits in the new app and did everything else in the old tools lost nothing. If it had gone badly we could have told them to go back, because the old tool was still sitting there.

Timesheets followed, then leads, then pipeline last. Pipeline is where reporting and the incentive calculations live, so it carried the most argument and the most people with an opinion about the numbers. Moving it last meant the platform had already earned some credit by the time that conversation started.

The dual-run period nobody enjoys

For several months the new platform and the old tools both held live data, which meant writing to both in places and reconciling the difference on a schedule. This is the work that gets cut from plans because it produces nothing a user can see. It is also the work that surfaces, well before cutover, the customer records two of the old systems had quietly disagreed about for years.

One thing we underestimated: what managers saw during the transition. A regional manager looking at a pipeline that is half in one system and half in another does not want a technical explanation of why. We ended up building a reporting view that read from both sources and labelled which figure came from where, then deleted it at the end of the migration. It was worth building. We should have planned it rather than discovered it.

The platform now carries the field force on one data model, with geolocation-verified visit records and route planning the old patchwork could not have supported. None of that was the hard part. The hard part was getting there without anyone losing a Tuesday.