When to Decide Power Platform ALM Strategy in Your Project Timeline

Microsoft's own Power Platform documentation explains managed and unmanaged solutions clearly: what each one is, and which of three common strategies fits a given project's scale. What it doesn't do is answer a scheduling question: when, on an actual project timeline, does this decision need to be locked in? This guide answers that one question, because getting the timing wrong is the more expensive mistake of the two.

The short answer

Before configuration starts. Not during the first sprint of configuration, not "early," but as a task or milestone that finishes before the first table, form, or flow gets built, with a real dependency link enforcing the order, not just an earlier date on the chart.

Why the order matters more than it looks like it should

Development happens in an unmanaged solution; that's simply how Dataverse solutions work, and it isn't a choice. The choice is the shape around it: one solution for the whole project, several solutions in one environment split by module, or a fully isolated development environment per application. That shape decides how tables, security roles, and flows get organized as they're built, not just how they're packaged afterward.

Configuration work built against the wrong shape doesn't stay wrong quietly. A table built inside the wrong solution boundary, or in a development environment that turns out not to match the isolation strategy the project actually needs, has to be reorganized before it can be exported as a managed build artifact and promoted safely. Reorganizing solution membership after components already have relationships to each other is real, avoidable rework, avoidable entirely by making the call before the first component exists.

What this looks like on a Gantt chart

Two ways to represent it, in order of how binding the constraint should be:

As a milestone, if the decision itself takes negligible time once the project's scale is known; a single-app rollout with one team rarely needs debate. Place the milestone before the first configuration task and don't allow configuration to start ahead of it.

As a task with a Finish-to-Start dependency, if the decision needs real discussion: comparing the three strategies against the actual number of apps, teams, and environments in scope. Draw the dependency from that task's finish to the first configuration task's start, the same way any other genuine blocking constraint gets modeled. See the dependency types guide for how Finish-to-Start differs from the other three link types, and when each is the right choice.

Either way, the placement is what matters: before configuration, with the chart actually enforcing it rather than the date simply happening to fall earlier by coincidence.

A concrete example, including a real trade-off worth naming

GanttFlow's Dynamics 365 implementation template places its ALM-strategy task inside Solution Architecture & Security, alongside security design and ISV evaluation. Only one of those three, solution architecture and the Dataverse data model, carries an explicit Finish-to-Start link into the first configuration task, Table & column configuration. ALM strategy itself is scheduled to overlap the first few days of configuration rather than fully finishing ahead of it.

That's worth calling out rather than glossing over, because it's a real trade-off, not an error in the template: architecture and ALM strategy are closely related decisions usually made by the same people in the same conversations, so scheduling them with some overlap reflects how the discussion actually happens. The risk is real too: if ALM strategy lands after Table & column configuration has meaningfully progressed, that's exactly the rework this guide opened with. The safer version of this template's approach, if the ALM conversation is likely to run long or involve more stakeholders than the architecture discussion, is to draw an explicit Finish-to-Start link from ALM strategy into configuration as well, not just rely on the two tasks happening to be scheduled close together.

What happens if this decision changes mid-project

Sometimes it has to: a project that starts as single-app scope and later adds a second app is a common trigger. When that happens, treat it as a real re-planning event, not a quiet adjustment: add a new decision milestone, reschedule from there, and expect some already-built configuration to need reorganizing into the new solution shape. The rescheduling guide covers how to move a chart's downstream dates without breaking the dependency chain when a plan changes mid-flight.