Migrating from PowerShell DSC to Microsoft DSC

Course content

This course takes you from a working PowerShell DSC estate to a Microsoft DSC estate, without a rewrite weekend and without breaking production. The planning module starts where every real migration starts: with an honest look at what you already own. You'll learn why the trajectory points to Microsoft DSC, build an inventory that classifies every resource on a machine, and use that inventory to assign each artifact to one of four migration paths.

Next, you'll walk all four paths against the same small legacy estate. You'll adapt a Configuration script into a configuration document with the resource code untouched, rescue a compiled MOF file whose source script is long gone, rewrite a script-based resource as a class-based one that runs on PowerShell 7, and learn the signals that justify a full native rewrite.

The final module deals with the part of PowerShell DSC that isn't a file: the Local Configuration Manager. You'll map every LCM behavior your estate might depend on to its Microsoft DSC equivalent, replace scheduled enforcement with something you own, move credentials out of MOF files, and run an end-to-end equivalence check that proves all three migration routes converge on the same machine state.

Prerequisites

Before starting this course, you should have:

• PowerShell DSC experience: You've written Configuration blocks, compiled MOF files, and run Start-DscConfiguration at least a few times.
• Microsoft DSC fundamentals: You can read a configuration document, and you've run dsc config get, dsc config test, and dsc config set against one.
• PowerShell scripting: Functions, modules, module manifests, and enough class syntax to read a [DscResource()] class.
• A Windows machine: With both Windows PowerShell 5.1 and PowerShell 7+ installed, plus the dsc CLI on your path. Administrator rights are needed for the machine-level environment variable used in the exercises.

Don't worry if you're rusty on the Microsoft DSC side. Each unit explains the construct before using it, and every command in the exercises is shown in full. The PowerShell DSC knowledge is the part that's hard to substitute, because this course is about translating something you already own.

[!TIP]
If you've never applied a configuration document with Microsoft DSC, work through the getting-started chapters of The Microsoft DSC Handbook or The Fundamentals of Microsoft DSC first. This course assumes the mechanics and focuses entirely on the translation.

What you'll learn

• Inventory a PowerShell DSC estate: Classify configurations, compiled MOFs, script-based resources, and class-based resources, and check what each Microsoft DSC adapter can already see.
• Choose a migration path per artifact: Apply a four-path decision framework — adapt in place, import MOFs, rewrite as class-based, rewrite as native — and defend the choice with cost and payoff, not preference.
• Execute each path hands-on: Translate Configuration scripts into configuration documents, convert MOF files with an import extension, and port Get/Set/Test-TargetResource trios into class-based resources.
• Replace the LCM: Map enforcement modes, refresh intervals, reboot policy, partial configurations, and cross-node coordination to explicit Microsoft DSC replacements that you schedule and own.
• Migrate credentials safely: Retire PSDscAllowPlainTextPassword and MOF encryption certificates in favor of secureString parameters and secret extensions.

By the end of this course, you'll have migrated a complete (if small) estate end to end, including:

• A migration inventory report you can run against any machine
• A configuration document that replaces a Configuration script
• A class-based resource ported from a script-based one
• A scheduled enforcement replacement for the LCM
• An equivalence check that proves the migration didn't change behavior

You'll understand the full lifecycle from "we have hundreds of MOFs and nobody remembers who wrote them" to a reviewed, tested, version-controlled Microsoft DSC estate.

The running example

Every unit uses the same fictional estate, owned by a company called Bindery. A bindery is a workshop where loose sheets are fastened together into books, which is a fair description of what a migration does: fasten an old estate to a new engine without tearing any pages.

Bindery's operations team owns:

• BinderyOps, a PowerShell module containing a script-based resource named AppEnvironment that manages a machine-level environment variable.
• LegacyWebServer.ps1, a Configuration script that uses AppEnvironment alongside the built-in File resource.
• output\localhost.mof, the compiled artifact that the LCM actually applies.

It's small enough to follow in a single sitting and structurally identical to the thousand-line resources in your production estate.