Software rollouts are one of the areas where we stay involved well past go-live. That’s deliberate.
A system that performs well in a demo and a system that holds up six weeks into real use are often two different experiences. We’ve worked through enough implementations alongside the teams we support to know where things tend to come unstuck, and more importantly, what to do about it before the problems compound.
This piece is a look at what we watch for during and after a rollout, and why that ongoing attention makes a practical difference to how things land.
What We Watch For During a Rollout
How the new system connects to everything else already running
Software rarely lives in isolation. It needs to pull data from existing systems, push outputs to others, and fit into workflows that were built around whatever came before it.
Integration issues tend to surface two to four weeks after go-live, once real volumes of data start moving through the system. By then, workarounds are already forming in the background. We watch for these early and work through them before they become a permanent part of how your team operates.
Whether the data carried across from the old system is actually usable
Moving data from one system to another surfaces inconsistencies that the old system had quietly absorbed for years. Duplicate records, formatting differences, fields that mapped in theory but not in practice.
Data preparation takes longer than most timelines allow for, and the quality of what gets migrated sets the ceiling on how well the new system performs from day one. We work through this carefully, because a clean migration handled well at the start saves a significant amount of rework later.
Whether the configuration still fits once real work starts flowing through it
Systems get configured before go-live, and then the business keeps moving. Processes shift, teams grow, new workflows emerge that nobody anticipated during setup. We review configuration as part of ongoing support, which is something we cover as part of our managed IT services. The goal is to make sure the system keeps pace with how you actually work, rather than the other way around.
How the team is adapting to the change in day-to-day use
A system being live is different from a system being used well. We pay attention to where friction is building, which roles are finding it hardest, and what the gap is between what the system was set up to do and what people are actually trying to do with it.
In one manufacturing environment we work with, a production scheduling tool was rolled out with solid training documentation. What the configuration hadn’t accounted for was that floor supervisors worked across two shifts with no practical way to hand off context between them inside the new system. The workaround they developed added time rather than saving it. We caught it at the four-week mark and rebuilt that part of the workflow.
Whether issues that come up after go-live have a clear path to resolution
Every rollout produces problems once real use begins. The ones that derail a project are usually the ones with no clear owner and no reliable escalation path. We make sure there is a structured way for your team to flag what isn’t working, that someone is tracking it, and that resolution doesn’t depend on whoever happens to have capacity that week. For organizations going through more significant technology change, our IT project support is built specifically around this.
Something We Worked Through With a Client Recently
A nonprofit we work with in the DC area moved their donor management and grants tracking into a new platform. The selection process was careful, the vendor was well-regarded, and the initial rollout appeared to go smoothly.
About eight weeks in, the picture had changed. Data migrated from the previous system was surfacing inconsistencies in donor records that the transfer process hadn’t caught. The development team and the finance team were pulling different figures for the same grants because each had been given access to different views of the same data without realizing it. A workaround document was already circulating internally.
The software itself was functioning as intended. The issues were in the configuration, what the migration had missed, and the absence of any process for raising and resolving problems that emerged after go-live.
We worked through each area. The data inconsistencies were corrected, the reporting structure was reorganized so both teams were drawing from the same source, and a simple process was put in place for ongoing issues to get logged and addressed.
The team lead told us a few months later that the platform was finally doing what they had originally been told it would. It just needed the right follow-through to get there, which is almost always the case.
Why We’re Sharing This
Software implementations come up regularly across the teams we work with, and the patterns repeat consistently enough that we think it’s useful to share what we see.
If you have something in your environment that never quite delivered on what was promised at the outset, or if a rollout is coming up that you’d like us more closely involved in, it’s worth a conversation. There’s usually more that can be done than people expect.
You might also find our piece on keeping your technology stack aligned as your organization grows useful reading alongside this one.