Skip to content

15 Migration from ALM Accelerator

Jump to bottom
RemyDuijkeren edited this page Jul 21, 2026 · 5 revisions

Migration from ALM Accelerator for Power Platform

The ALM Accelerator for Power Platform was a Microsoft-built canvas app and Azure Pipelines YAML toolkit for automating solution export, branch management, solution checker runs, and multi-environment deployment. It was deprecated in 2025. Microsoft's stated replacements are Pipelines for Power Platform (low-code GUI pipeline) and Dataverse Git Integration (source-as-truth sync).

Neither replacement supports code-first ALM — plugins, web resources, and Custom APIs. Flowline fills that gap.

Deployment model: what changes

This is the most important thing to understand before migrating.

ALM Accelerator was designed for environments with multiple makers you do not fully control. It treated source control as the coordination layer: export from DEV → commit to branch → PR → solution checker → pipeline deploys. Makers worked in a shared DEV environment and the pipeline was the gatekeeper.

Flowline assumes your team owns the DEV environment. DEV is truth. flowline sync pulls the current DEV state into source control as unpacked XML (git-diffable). flowline deploy {env} promotes to Test, UAT, or Prod. There is no PR-based promotion — you sync when DEV is ready, then deploy when the commit is tested.

ALM Accelerator Flowline
DEV environment Shared, multiple makers Team-owned
Source of truth Source control (after export) DEV environment
Promotion trigger Pull request + pipeline flowline deploy {env}
Code-first ALM Delegates to developer's existing tooling First-class (push, generate)

If your team does not own the DEV environment (shared maker environment, ISV model, AppSource distribution), Flowline is not the right fit. Use Pipelines for Power Platform for the no-code pipeline and manage code-first components separately.

What maps to what

ALM Accelerator Flowline Notes
Solution export → ADO branch commit flowline sync Exports from DEV, unpacks to Solution/src/, git-ready
Solution import to Test flowline deploy test Packs from source, imports unmanaged
Solution import to UAT flowline deploy uat With DTAP version-check gate
Solution import to Prod flowline deploy prod With DTAP version-check gate
Plugin assembly deployment flowline push --scope plugins
Web resource deployment flowline push --scope webresources
Plugin + web resource deployment flowline push
Solution version increment flowline sync --bump patch Auto before export
Early-bound type generation flowline generate
Bootstrap from existing solution flowline clone
Verify connection flowline status
Service principal auth (CI/CD) pac auth create --kind ServicePrincipal
Per-env deployment settings (conn refs, env vars) No equivalent See Known gaps
Solution Checker in pipeline flowline deploy (built-in gate) Blocks on Critical findings automatically — see 07-Deploy#solution-checker-gate
PR / ADO approval gate Partial — DTAP version-check See DTAP gates
Azure Pipelines YAML templates Manual — see Step 5 No generator yet
Deployment history No equivalent
Teams / email notifications No equivalent
Canvas admin app (maker portal) No equivalent — Flowline is CLI-only

Before you start

  • Install PAC CLI: dotnet tool install --global Microsoft.PowerApps.CLI.Tool (Windows alternative: winget install Microsoft.PowerAppsCLI)
  • Install Flowline: dotnet tool install --global Flowline
  • Authenticate to your DEV environment: pac auth create --environment https://your-dev.crm4.dynamics.com
  • Verify: flowline status

Two-phase migration strategy

Running everything in one pass is possible, but splitting the migration into two phases reduces risk — only one thing changes at a time, so problems are easier to diagnose.

Phase 1 — Code-first components only (ALM Acc pipeline stays running)

Replace ALM Accelerator for plugin registration and web resource sync using Flowline's standalone mode. Your existing ALM Acc export and deploy pipeline keeps running unchanged. This is safe: flowline push only touches plugin steps and web resources — it does not interact with the solution packaging pipeline.

# Plugins only
flowline push MySolution --pluginFile ./bin/Release/MyPlugins.dll --dev https://your-dev.crm4.dynamics.com

# Web resources only
flowline push MySolution --webresources ./WebResources/dist --dev https://your-dev.crm4.dynamics.com

# Both at once
flowline push MySolution --pluginFile ./bin/Release/MyPlugins.dll --webresources ./WebResources/dist --dev https://your-dev.crm4.dynamics.com

Always verify with --dry-run first. Once phase 1 is stable, ALM Acc is no longer needed for code-first component management.

Plugin registration attributes: ALM Accelerator did not define its own plugin registration attribute system — it deployed your existing assembly regardless of how steps were declared. If you are currently using spkl, Daxif, or PACX attributes, see the corresponding migration guide for the attribute replacement step. This guide focuses on the ALM pipeline.

Phase 2 — Full pipeline replacement (retire ALM Acc)

Set up the Flowline project structure and replace ALM Acc's export and deploy pipeline stages with flowline sync and flowline deploy. The steps below cover Phase 2.

Step 1 — Bootstrap the project

Bootstrap the project structure from the existing solution in your DEV environment:

flowline clone MySolution \
  --dev  https://your-dev.crm4.dynamics.com \
  --test https://your-test.crm4.dynamics.com \
  --prod https://your-prod.crm4.dynamics.com

This creates:

  • .flowline — environment URLs and solution config
  • Solution/ — <SolutionName>.cdsproj and unpacked solution XML
  • Plugins/ — <SolutionName>.Plugins.csproj
  • WebResources/ — <SolutionName>.WebResources.csproj

The unpacked solution XML in Solution/src/ is what you commit to source control — the same content ALM Acc exported and committed to ADO branches.

Step 2 — Replace solution export

ALM Accelerator exported the solution from DEV and committed the result to an ADO branch. flowline sync does the same in one command:

# ALM Accelerator flow:
# Canvas app → Export → commit to ADO branch → open PR

# Flowline
flowline sync

flowline sync exports the solution from DEV, auto-bumps the patch version, unpacks it to Solution/src/, and leaves the files ready for git commit. You control the commit and branch strategy — Flowline does not open PRs or manage branches.

# Typical sync → commit flow
flowline sync
git add Solution/src
git commit -m "sync: MySolution patch bump"

To skip the auto-bump (re-sync without incrementing the version):

flowline sync --bump none

Step 3 — Replace solution deployment

ALM Accelerator ran pack + import inside Azure Pipelines. flowline deploy does the same:

# ALM Accelerator pipeline:
# Pack → solution checker → import to Test → (PR approval) → import to UAT/Prod

# Flowline
flowline deploy test
flowline deploy uat
flowline deploy prod

flowline deploy {env} reads the environment URL from .flowline, packs the solution from Solution/src/, imports it to the target, and runs pre/post-import orphan cleanup automatically. The target environment must be authenticated (see Step 4).

Step 4 — Replace authentication

ALM Accelerator stored service principal credentials in Azure Pipelines variable groups and connected them to environment service connections. Flowline reuses the PAC CLI token cache — no credentials in Flowline's own config.

For interactive use (DEV, daily work):

pac auth create --environment https://your-dev.crm4.dynamics.com

For CI/CD (service principal per environment):

# Test
pac auth create --kind ServicePrincipal \
  --applicationId $CLIENT_ID \
  --clientSecret $CLIENT_SECRET \
  --tenant $TENANT_ID \
  --environment https://your-test.crm4.dynamics.com

# Prod (repeat for each additional environment)
pac auth create --kind ServicePrincipal \
  --applicationId $CLIENT_ID \
  --clientSecret $CLIENT_SECRET \
  --tenant $TENANT_ID \
  --environment https://your-prod.crm4.dynamics.com

Run flowline status to verify all environment connections are active.

Step 5 — Wire up CI/CD

ALM Accelerator provided Azure Pipelines YAML templates out of the box. Flowline has no generated templates yet — the examples below are starting points to adapt to your repo.

GitHub Actions

name: Flowline Deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install tools
        run: |
          dotnet tool install --global Microsoft.PowerApps.CLI.Tool
          dotnet tool install --global Flowline

      - name: Authenticate to Test
        run: |
          pac auth create --kind ServicePrincipal `
            --applicationId ${{ secrets.CLIENT_ID }} `
            --clientSecret ${{ secrets.CLIENT_SECRET }} `
            --tenant ${{ secrets.TENANT_ID }} `
            --environment ${{ secrets.TEST_ENV_URL }}

      - name: Build plugins
        run: dotnet build Plugins/MySolution.Plugins.csproj -c Release

      - name: Push plugins
        run: flowline push --scope plugins

      - name: Deploy to Test
        run: flowline deploy test

Add a separate job (or workflow) gated on the Test job for UAT/Prod promotion.

Azure Pipelines

trigger:
  - main

pool:
  vmImage: windows-latest

steps:
  - task: PowerShell@2
    displayName: Install tools
    inputs:
      targetType: inline
      script: |
        dotnet tool install --global Microsoft.PowerApps.CLI.Tool
        dotnet tool install --global Flowline

  - task: PowerShell@2
    displayName: Authenticate to Test
    inputs:
      targetType: inline
      script: |
        pac auth create --kind ServicePrincipal `
          --applicationId $(ClientId) `
          --clientSecret $(ClientSecret) `
          --tenant $(TenantId) `
          --environment $(TestEnvUrl)

  - task: DotNetCoreCLI@2
    displayName: Build plugins
    inputs:
      command: build
      projects: Plugins/MySolution.Plugins.csproj
      arguments: -c Release

  - task: PowerShell@2
    displayName: Push plugins
    inputs:
      targetType: inline
      script: flowline push --scope plugins

  - task: PowerShell@2
    displayName: Deploy to Test
    inputs:
      targetType: inline
      script: flowline deploy test

Use Environments in Azure Pipelines to gate UAT and Prod stages behind manual approvals while Flowline's native approval gate feature is not yet available.

DTAP gates

ALM Accelerator used ADO PR approval status to gate promotion between environments. Flowline enforces DTAP gates differently today:

  • DEV block: flowline deploy refuses to run against a DEV environment. Deployments always flow from packed source (Solution/src/), never from DEV to another environment directly.
  • Version check: deploying to UAT or Prod checks that the predecessor environment already carries the version being deployed — you cannot skip environments. Deploying v1.2 to Prod fails if UAT is still on v1.1; promote to UAT first.

There is no PR-based or tag-based approval gate in the current version of Flowline. Gating Prod deploys today means restricting who can trigger the pipeline stage that runs flowline deploy prod — use Azure DevOps Environments approval or GitHub Actions environment: production protection rules.

Known gaps

Per-environment deployment settings

ALM Accelerator's most-cited feature was its per-env deployment settings JSON — a file committed to source that mapped connection reference names to connection IDs, and environment variable names to values, per target environment. After import, the pipeline applied these settings automatically, enabling fully unattended CI deploys.

Flowline has no equivalent today. After flowline deploy test, connection references and environment variable values must be configured manually in the target via the maker portal or PAC CLI.

Tracked as a planned feature — see 12-Planned-Features#flowline-configure--post-deploy-state-reconciliation.

PR-based approval gate

ALM Accelerator gated Prod deployments on ADO pull request approval. Flowline's DTAP gate today is a version-check only — it verifies the source version is higher than the target, but does not require a separate approval action. Use your CI platform's environment protection rules as the gate until a native Flowline approval mechanism is available.

CI/CD templates

Flowline does not yet generate CI/CD YAML from the project config. The examples in Step 5 are starting points you maintain manually. Adapt the solution name, environment secrets, and project paths to match your repo.

Clone this wiki locally