What a $2M migration looks like from the inside

The engagement

In 2022, we closed and delivered a CAD $2.4M multi-year digital transformation for a provincial government in Eastern Canada. At the time, it was the largest single engagement in the history of the firm we were part of. The scope included a cloud migration, a low-code platform deployment, a data foundation, and a managed services handover.

This is an account of what actually happened — what we got right, what we got wrong, and what we would do differently. Names and identifying details are withheld, but the substance is accurate.

What we got right

Starting with the stakeholder map, not the technical architecture. The most consequential decision we made in the first two weeks was investing heavily in understanding who had authority over what — not who the official project sponsors were, but who could actually block progress in the ministry. That map saved us months of avoidable friction.

Treating the data foundation as a prerequisite, not a parallel track. Every organization that has run a digital transformation has a version of the same regret: we should have fixed the data first. We knew this going in and structured the engagement so that the data foundation work was sequenced before the platform deployment rather than alongside it. That decision alone avoided what would have been a painful retrofit.

Fixed weekly written status to all stakeholders, every week. Government procurement environments are sensitive to surprises. We sent a one-page written status update every Friday — progress, upcoming milestones, risks open, risks closed — to the full stakeholder list including the CIO's office. It sounds administrative. It was, in practice, our most effective risk management tool.

A named person accountable for the managed services handover from day one. We designated the future managed services lead at contract signature, not at go-live. That person was present at every design decision that touched the operational model. By the time we handed over, there was nothing in the environment they had not seen being built.

What we got wrong

Underestimating procurement cycle time in the extensions. The initial contract was structured in phases with options to extend. Each extension required a new procurement action, which we initially modeled at 4–6 weeks. The actual cycle time was 10–14 weeks. This created three separate gaps in delivery momentum and two periods where the team was partially stood down. In a future engagement of this type, we would build procurement runway into the project schedule explicitly.

The low-code platform migration scope changed three times. The ministry's original scope for the low-code platform was clearly defined. Over the course of the engagement, three significant changes were requested — each reasonable in isolation, each absorbing capacity. We managed the change requests professionally, but we could have contained scope drift earlier by building a more explicit change threshold into the SOW.

We waited too long to surface a resourcing risk. In month eight, a key architect on the team accepted a permanent role elsewhere and gave four weeks' notice. We had not maintained a bench with deep familiarity with this engagement's context, and the replacement ramp-up cost us three weeks of effective delivery time. The lesson: in a multi-year engagement, succession planning for key roles is not optional.

What we would do differently

Run a formal lessons-learned session at 12-month intervals, not just at project close. In a 30-month engagement, the lessons from month 12 are still actionable in month 18. By the time you reach project close, the team has half-forgotten the issues that cost them the most time.

Invest more heavily in internal capability transfer throughout the engagement, not just at handover. The ministry staff who were most effective post-handover were the ones who had been actively involved in build decisions. The ones who had been passive recipients of documentation struggled, regardless of the documentation quality.

And charge more for the first phase. The pricing on the initial phase was aggressive to win the work. It created a margin problem in year one that required careful management and limited our ability to bring in outside expertise when we needed it most. The subsequent phases were priced correctly. The lesson is obvious in retrospect.