Many organisations have run their casework on the same system, or the same mix of systems and spreadsheets, for years. Replacing it is as much about people as technology, and a new system only delivers if the people using it every day are on board. If you're about to replace yours, this is the reality check we'd give you, drawn from what we learned the last time we did it.
The first step in moving off a legacy system is to find the essential, day-to-day work the organisation can't do without. That might be one business process, several running at once, or the work of a single department. Depending on the client and their legacy systems, the first release might be a clean switch from old to new, or the new system might run alongside the old one with the two integrated. Starting with the highest-value work proves the new system where it matters most and gives staff something real to use early. From there it can take on more of the organisation's processes, one area at a time.
The harder part is resisting a straight like-for-like swap. The early releases may well need to match what the old system did, because the work can't stop. After that, the more useful question is what the new system could do for the organisation. Technology moves quickly, and copying a design from a system built years ago throws much of that away, so we'll challenge like-for-like when it isn't the best option and show clients what's now possible.
Caseworkers use the system all day, validating and analysing forms as they come in, so they were central to our planning.
We found in-person workshops the best way to understand what the new system really needed to do, because many caseworkers had processes baked in from decades with the old system. The workshops separated the policy and guidance that exists for the organisation's work from the rules that only existed to cope with a clunky, ageing system. The first belongs in the new system and the second usually doesn't.
Some people really took to being part of the project. They got invested in the technology, wanted to learn more and became its best advocates across the wider organisation. A colleague saying the new system works, often carries more weight than anything the project team can say.
Data migration can cause problems when it isn't tackled early enough. Few organisations have one tidy database. Most have data spread across databases, SharePoint sites and a long tail of spreadsheets and exported files. That's manageable as long as it's known, and the hardest part is often finding where the data really lives and drawing a line around it. We then help the client decide what is no longer required and can be deleted, what can stay where it is and be referenced by the new system, and what has to move.
Migration needs the same visibility as any other work. It belongs in stand-ups and on the team's board, broken into chunks small enough to report on, so the risk is clear as go-live nears. Once the data is bounded, we build the transformations into the new system's format, ready for loading.
Testing is a joint effort. We handle the volume, checking each run moves the expected data and running automated checks across thousands of records so repeat runs don't drift. The client's people know their data best. They know which records were always awkward in the old system, and they'll want to see how those look in the new one. We help prepare them for user acceptance testing (UAT) so their time goes on the cases that matter.
Decide early who will look after the system once it's live, because that should shape the platform. An organisation with its own software development team may want a solution built on the tech stack that team already knows. Most don't have a team with the capacity to take that on, and for them a low-code platform such as Appian is often the better fit. It's largely visual, so IT staff can administer and support it without specialist programming skills, while developers still have the depth they need. The vendors' own courses and learning environments mean a committed person can learn to maintain and extend the solution in a fairly short time.
Whichever way the client goes, we plan the handover from the start rather than in the final sprint. If their team will own the system, we involve them in technical decisions throughout and train them on both the platform and the solution, so there's no gap when we step back. The client should be able to choose whether we stay on to support it, not need us to.
Every client handles this differently. Some draw subject matter experts (SMEs) from across the business to work on the project full or part time. They're known faces, so communication is easy and the project has people it can rely on, and rotating them now and then brings fresh ideas into workshops.
Other clients can't spare people full time. That's harder, so structure matters even more. A fixed weekly routine means the key sessions still happen, and we can place our own people on the client's side to pick up work such as planning UAT, which takes a lot of admin off busy SMEs. The best set-up we find is a permanent project manager, product owner and business analyst, with key permanent or semi-permanent SMEs who bring their knowledge and experience to the project.
The senior responsible owner (SRO) is one of the most important roles on a project. They step back from the day-to-day and steer its direction, deciding who joins or leaves the project, what gets prioritised and how escalated issues are resolved. Requests for extra scope arrive on every project, and the SRO is the person who can say yes, not yet or no, so the team isn't left guessing. A product owner working closely with the SRO and project manager can take on much of this and protect the SRO's time.
Sign-off matters just as much. In discovery we agree a definition of done, so everyone knows what "complete" looks like before work starts. Each piece of work can then be signed off as built and tested to specification, which gives a clear record of what changed and who agreed it. Without that, delays build up and work can stall.
We tier training by role. IT teams get technical training on the platform and on the solution built on it. Everyone else gets training on the whole system, so they understand how their work fits with everyone else's, and then more in-depth training on the screens they use in their role. Training happens more than once, timed to milestones such as the first release or a new module going live, so people learn close to when they'll need it.
People love or loathe their old system. Spending hours a day looking at the same screens leaves an emotional mark, and that matters when you ask them to give it up.
Designing a new system is exciting, and for many people it's the first time they've been asked to bring their experience and ideas to how it should work. A branding session where users help name the system and shape its look builds real attachment. It becomes their system rather than a generic set of screens they've been handed.
Agree the measures up front. Some are simple, such as cases completed, forms processed or deliveries made. Others are subtler. Some organisations work in areas that don't suit KPIs, where the quality of each decision matters more than the number made, and their measures before and after the new system may look completely different. We agree these in discovery, and that view of what good looks like shapes everything we build.
Numbers only tell part of the story. Regular user experience sessions show what is and isn't working for the people using the system, and often surface things neither our team nor the client's project team had thought of. Working in an agile way means those findings go into the backlog and get delivered, not left waiting for months or years.
The new system also changes what can be measured. In our experience its reporting is granular enough that organisations can track things they had no sight of before.
Here's how we can help.
Process automation and case management
Want more content like this? Sign up to our monthly newsletter!