I shared my thoughts on the CoE Starter Kit a while ago. Long story short: it’s a great foundation, a toolkit to build on and adapt to your organization’s needs. Microsoft recommends upgrading the kit at least every 3 months.

Let’s be honest for a second… how many organizations actually do that?

🖐️ I do!
And with this post, I am sharing reusable Azure DevOps pipelines to help more organizations better manage their CoE Kit upgrades.

Why Upgrading the Kit Matters

I am not the only one to say it… Microsoft suggests to upgrade the kit every three months.

Let’s list the main below:

1. Bug Fixes: there are and will always be some bugs to fix. At the time of writing this article, there are 95 open bugs in the GitHub. It does not mean the kit is not working well, it just is the nature of any software solutions. These bugs can have an impact on the visibility admins get over the tenant inventory and usage. Upgrading the kit regularly allows to resolve these issues and improve visibility.
2. Platform Evolution: the platform evolves fast. Older kit versions do not provide visibility over the feature which did not exist at the time.
3. Performance: for large tenants, API Calls optimization is key to run the kit efficiently. The most recent sync flows in the kit consume significantly less API calls than the former versions.

Does it need an upgrade every 3 months? It does seem like a good frequency to me, though always possible to regularly check the kit release notes and assess whether the CoE Kit upgrades make sense, based on the planned enhancements and bug fixes.

Recommended CoE Kit ALM Approach

I did mention it in this former post, but I’ll repeat it here: Microsoft calls it the “CoE Starter Kit” because it is as a starting point for organizations to further build on and customize to their specific needs. If we customize this kit of 400+ resources, we better have a proper ALM approach to avoid issues in production.

I personally like to adopt a 3-4 environments approach.

SOURCE Environment

This environment only hosts the kit as managed and out of the box, with no customization. This allows to confirm that the flows are running fine.

DEV Environment

This environment has the kit installed as managed as well, and also host the unmanaged solutions with any customization. If you would like to customize the data model, create additional cloud flows etc., this is where you would do it.

If there is ever a need to modify an existing flow from the kit, best is to duplicate the flow, rename it to clearly identify that it is a custom version, and turn off the original flow. This will avoid an unmanaged layer on top of the original flow which will impact the behaviour of future upgrades.

I also suggest to segregate the customization into different unmanaged solutions. Each unmanaged solution can be responsible for a specific topic / area of customization, with its own connection references. This helps keep things tidy and make things easier when you start to have a of customizations.

TEST Environment (Optional)

This environment serves the purpose to test the deployment process. It is ideal to have it, especially when you start to have many customizations. This environments host all the solutions as managed to mimic Prod. It is ideal to have one, but also manageable without one at first.

PROD Environment

Hosts all solutions as managed. This is the only environment which should have the Sync Flows turned on. Best is to turn off all the automated Sync Flows from the other environments to avoid an explosion of API Calls.

Overview of the Three Reusable Pipelines

Pipelines can make significant improvements to improve the upgrade process and make it more efficient. There are two main options to automate the CoE Kit Upgrades with Pipelines: Azure DevOps Pipelines or GitHub Workflows. In this post I share Azure DevOps pipelines, but I am sure a LLM would convert this to GitHub workflows in no time if needed.

I am sharing 3 Pipelines: Sync, Generate-SampleSettings, and Deploy. You can check them out in my GitHub repo below, where you will find the detailed set up instructions. It can take some time to set up, but is definitely worth it in the long run in my opinion.

The Sync Pipeline

This pipeline proceeds as below:

1. Download the latest version of the CoE Kit Core Components Solution
2. Unpack it into the Azure DevOps repo
3. Generate/Update 3 deployment setting files in the repo for the deployment to SOURCE, DEV and PROD environments (can easily support TEST as well)
4. Commit the change into a new branch and opens a PR if there is any change

Locally unpacking the solution can make it easier to track the changes from one version to the next. The deployments setting files are helpful for the first deployment and when a new variable or connection reference is introduce. This helps to ensure everything will be mapped in the target environment.

The repo will then have a structure like below, with easy customization possible by adjusting the script if necessary: a root folder for the solution, sub folder for the unpacked code, and a subfolder for the deployment settings file:

The Generage-SampleSettings Pipeline

This pipelines is by no mean mandatory. It generates a sample settings deployment file from an existing environment. It populates the settings deployment file with the values defined in an environment where the kit is already installed.

The pipeline commits the file to the local Azure Devops repo. It can be helpful to be reminded of the required format of the variables in the file, which are not always intuitive, such as “yes” and “no” for Boolean variables.

The Deploy Pipeline

This pipeline is the one making the actual CoE Kit upgrades. It proceeds as below:

1. Pack the solution in the local repo
2. Import the solution in the target environment (SOURCE, DEV or PROD) using the values from the deployment setting file
3. Publish the unmanaged and managed solution as pipeline artifacts

Setup and Prerequisites

Setting up these pipelines requires a few pre-requisites. I share the instructions in more details in my GitHub repo, but here is a high-level summary of what is required.

• In Azure
  • App(s) registered to authenticate to each environment and perform the required operations
• In the Power Platform
  • Environments Created and Creator Kit installed
  • App Users associated to the Azure Apps created in each target environment
• In Azure DevOps
  • An Azure DevOps organization, project and repo
  • At least one Microsoft-hosted parallel job
  • Power Platform Build Tools extension installed
  • Power Platform Service Connections created for the Azure DevOps project for each environment
  • Pipelines created and customized as needed
  • Appropriate permissions managed in the Repo to ensure the pipelines can run successfully

Extending the Pipelines

These pipelines can easily be extended to cover the below scenarios based on the needs:

• Automatically install the Creator Kit if not already in the environment. This can be done by modifying the deploy pipeline directly.
• Automatically trigger the Sync pipeline when a new CoE Kit version is released. One way it can be done for example is by subscribing the the CoE Kit GitHub updates and create a Flow to trigger the pipeline when a new release is announced.
• Automatically trigger the Deploy Pipeline when the Sync Pipeline has completed and a PR is completed. Simply adjusting the pipeline trigger would do just fine for this, if this is a requirement.

Conclusion

Doing CoE Kit upgrades regularly isn’t just a best practice, it’s essential for maintaining visibility, performance, and alignment with the evolving Power Platform. By combining a clear ALM strategy with reusable Azure DevOps pipelines, organizations can turn what often feels like a complex, manual process into a predictable and efficient workflow.

This approach not only reduces risk during upgrades but also ensures customizations remain organized and future-proof. Investing time upfront in automation pays off with smoother operations and a more sustainable Center of Excellence.