In migration and modernization projects, one misconception persists: the belief that you can pick up the pace without giving the early stages the attention they require. Yet these are precisely the stages that provide an accurate picture of the environment, gauge how ready the teams are, and bring together the conditions for disciplined execution. Cutting them short, underestimating them, or skipping them inevitably undermines every step that follows. A trajectory gets promised to an executive committee before anyone truly understands the starting point. A few weeks later, the realization sets in: the project was never accelerated, only burdened with more problems.
Why does moving too fast too early cost more later?
The first critical moment comes before the delivery contract is even signed. It starts with the preliminary analysis. Its purpose is not to work through every detail, but to build a somewhat reliable understanding of the current state that the project rests on facts rather than assumptions. This is where the technical and commercial foundations of the execution contract take shape. In some cases, this stage becomes a separate mandate of its own, precisely so the client can support an internal budget request with a more factual understanding of their environment. Without that groundwork, neither a price nor a trajectory is genuinely confirmed. What remains instead are grey areas that will surface during execution.
This is also the stage where items the organization rarely knows as well as it thinks begin to emerge: major dependencies, pockets of complexity, operational constraints, thin documentation, fragile assumptions. Skipping this work, or giving it less effort than it deserves, does not make those realities disappear. It simply defers them to a point where the project is already underway and every additional discovery costs more to absorb.
What should the preliminary analysis actually establish?
The second critical moment arrives when the project truly begins. In Alithya's methodology, this is the planning and strategy stage. Here, the initial understanding is tested against real execution conditions. Access is confirmed, teams are mobilized, the client's structure comes into sharper focus, and the work can go deeper into architecture, components, flows, configurations and, where needed, portions of the code. The goal is no longer just to understand the environment. It is to organize what comes next in concrete terms: defining how each system will be migrated, structuring the waves, settling the technical choices, and confirming the conditions required for credible execution.
Why can't the planning and strategy phase be skipped?
This is often the stage some want to bypass to accelerate the process. But setting planning and strategy aside simplifies nothing. It pulls execution into the project before the minimum conditions are in place. Dependencies, missing access, incomplete environments, and unwritten operating rules do not disappear. They resurface later, mid-sprint, as blockers, rework, and lost control. This echoes what several recent analyses of large technology programs point out: the difficulties stem less from a lack of ambition than from gaps in planning, interdependency management, resource mobilization, and delivery discipline.
Alithya's experience on mandates of this nature demonstrates that when the planning and strategy stage is bypassed to get the first migration work under way sooner, the result is usually the opposite of what was intended. The reasoning seems straightforward: save time and show visible results faster. In practice, the minimum conditions for execution are not yet in place. In a migration, access is never a matter of a few authorization layers. It often means dozens of technical permissions, some of them highly specialized, needed to analyze, prepare, validate, and execute properly. When several of those are not granted, or granted only in part, teams end up entering execution without the level of readiness that rigorous progress demands.
What happens when an essential stage is bypassed?
What followed was predictable: difficulty making progress, delays piling up, expectations missed from the very first iteration, mounting pressure on the teams, and then the need to hurriedly redo the planning and strategy stage that had been avoided in the first place. The project had not moved faster. It had simply pushed its difficulties to a point where they cost more and left fewer options. This is why the two stages need to be clearly distinguished. A preliminary analysis up front to reduce uncertainty, clarify the real conditions for success, and give the contract more credible foundations. Then a planning and strategy stage at project launch to turn that initial understanding into execution that can genuinely be controlled. This logic aligns with the AWS “assess” and “mobilize” phases, presented as the necessary foundation of any large-scale migration. Trying to accelerate without giving these stages the attention, the effort, and the conditions they require does not shorten the project. Above all, it weakens what comes after.
Sources and references
AWS Prescriptive Guidance (2025). Phases of a large migration. This guide presents the assess, mobilize, and migrate phases as sequential, and specifies that assess and mobilize form the necessary foundation of any large-scale migration.
AWS Prescriptive Guidance (2025). Mobilize your organization to accelerate large-scale migrations. The document notes that the assess and mobilize phases serve to prepare the organization, close readiness gaps, put technical foundations in place, and mobilize resources ahead of large-scale execution.
Boston Consulting Group (2024). Most Large-Scale Tech Programs Fail: Here's How to Succeed. BCG reports that more than two thirds of large technology programs are not delivered on time, on budget, or within the intended scope. The causes highlighted include weaknesses in planning, resource mobilization, interdependency management, and delivery discipline.
Project Management Institute (2024). Maximizing Project Success. The report stresses the need to clarify success parameters up front, maintain an evolving reading of project conditions, and connect execution to the value stakeholders actually expect.