I know that because I’ve been opening the portal several times a day and looking. There’s a customer deadline on this run, and if the failures turn out to be a pattern rather than three unlucky sites, I want to stop the whole thing before it creates 9,000 more. So I check. Manually. Like a night watchman without a bell.

Three failures out of ten thousand is a rounding error until it’s the three sites belonging to the customer who calls.

A Failed Orchestration Tells Nobody

Here’s the thing that makes this harder than it sounds: nothing surfaces a failed orchestration on its own.

My orchestrator wraps the whole run so a failure gets written to the status list before it propagates:

private async Task<ProvisioningContext> ExecuteProvisioning(Func<Task<ProvisioningContext>> action)
{
    try
    {
        return await action();
    }
    catch (Exception ex)
    {
        _logger.LogError(ex, "Provisioning failed.");

        // Try to update status, but never let a status-update failure mask the original error.
        try
        {
            await TryUpdateStatus(errorMessage: ex.Message);
        }
        catch (Exception statusEx)
        {
            _logger.LogWarning(statusEx, "Failed to update status after provisioning error.");
        }

        throw;
    }
}

That bare throw; is the load-bearing line. Because the exception isn’t swallowed, the instance ends in runtime status Failed instead of quietly finishing as Completed with half a site behind it. Good. But Failed is a row in a storage table and a red badge in a tool nobody has open at 21:00.

And getting there takes a while. Every activity call runs under a retry policy of 10 attempts with exponential backoff from 5 seconds up to 5 minutes, so an activity that can’t succeed spends roughly 25 minutes failing before the orchestration is allowed to give up. The hub association step is the reigning champion: JoinHubSite can return 200 and silently do nothing on a freshly created site, so the activity reads the association back and throws a plain InvalidOperationException when it didn’t stick. Plain, on purpose, because that one usually is transient. It gets all ten attempts before the orchestration dies. If you want the other half of that story, permanent versus transient failures is about which exceptions deserve the full ten.

So the failure is real, it’s slow, and it’s silent. I needed the bell.

Three Ways to Get Told, and Why I Picked the Boring One

I had three options on the table.

Publish an Event Grid event when the orchestration fails. I already run Event Grid in this solution, so the plumbing exists. But it means code in the failure path, a new event type, a subscriber, and a deployment. And every time I want the notification to say something slightly different, that’s another deployment.

A timer-triggered watchdog. A function that wakes up every N minutes, queries the instance table for anything in Failed, and shouts. Also code, also a deployment, plus its own state to remember what it already shouted about. Now I have two things to monitor: the pipeline and the thing watching the pipeline.

A log search alert in Application Insights. No code at all. The Durable Functions extension already writes lifecycle events for every orchestration, and I already have an action group wired up for this customer’s other alerts. Write a KQL query, point an alert rule at it, done.

I picked the third one, and the deciding argument wasn’t elegance. It was that I bill by the hour. The alert costs about $1.50 a month; writing and deploying either of the other two costs more than that in the first fifteen minutes, and then keeps costing every time it needs a tweak. The KQL, by contrast, I can widen tomorrow, from the portal, without touching the function app.

The two code options are better if you need the failure to do something automatically. Mine only needs to reach a human.

Durable Functions Already Logs Every Failure

The reason no code is needed: the Durable extension emits tracking events to Application Insights for every lifecycle transition, under the log category Host.Triggers.DurableTask. They land in the traces table, and everything useful is hiding in customDimensions behind a prop__ prefix.

This is the query behind the alert:

traces
| where customDimensions.Category == "Host.Triggers.DurableTask"
| extend functionName = tostring(customDimensions["prop__functionName"])
| extend functionType = tostring(customDimensions["prop__functionType"])
| extend instanceId   = tostring(customDimensions["prop__instanceId"])
| extend state        = tostring(customDimensions["prop__state"])
| extend reason       = tostring(customDimensions["prop__reason"])
| extend isReplay     = tobool(tolower(customDimensions["prop__isReplay"]))
| where isReplay != true
| where functionType == "Orchestrator" and state == "Failed"
| project timestamp, functionName, instanceId, reason, appName = cloud_RoleName

What’s happening here?

1. The category filter is the whole trick. Host.Triggers.DurableTask is the extension’s own channel, separate from anything my code logs, so the query keeps working no matter how I change my own logging.
2. The extend block lifts the tracking fields out of the dynamic customDimensions bag and casts them to strings. Without tostring, comparisons against dynamic values get weird in ways that cost you an afternoon.
3. isReplay != true drops replayed history. Orchestrators replay their execution constantly, so without this filter a single failure can produce the same tracking event more than once, and your alert email count stops meaning anything. I wrote it in defensively from the start rather than learning it the fun way.
4. functionType == "Orchestrator" is the difference between “a run failed” and “an attempt failed”. Activities emit Failed events too, and with a 10-attempt retry policy a perfectly healthy orchestration produces a pile of them on the way to succeeding. Filter to the orchestrator and you get one row per genuinely dead run.
5. reason carries the error details, so the alert email arrives with the instance ID and the actual message. That’s the difference between “go look” and “here’s what broke”.

The Alert Rule, Setting by Setting

Nothing exotic, and that’s the point:

• Signal name: Custom log search
• Query type: Aggregated logs
• Measure: Table rows, Aggregation type: Count, Aggregation granularity: 5 minutes
• Threshold type: Static, Operator: Greater than, Threshold value: 0
• Frequency of evaluation: 5 minutes

Static threshold, not dynamic. Dynamic thresholds learn a baseline and alert on deviation, which is the right tool for something with a natural rhythm. The natural rhythm of failed provisioning runs is zero. Any row is an incident, not an anomaly.

Threshold 0 on row count with a 5-minute window means “tell me about the first one”, which is exactly what I want during a bulk run. Three failures out of ten thousand is fine. Three failures in ten minutes means the hub is down and I should stop the queue.

The action group sends mail to me and to the customer’s IT department. That second recipient changed how I write the alert description: it has to make sense to someone who has never seen a task hub. The description says what failed, where the instance ID can be looked up, and who does what next.

Why Would the Alert Miss a Failure? Sampling.

Application Insights samples telemetry under load, and traces is sampled by default. A high-volume run producing thousands of lifecycle events per minute is exactly the situation where sampling starts dropping rows - including, possibly, the one you’re alerting on.

This is also the answer to the more general complaint that Azure Functions invocation logs go missing sometimes, or that App Insights alerts miss exceptions that definitely happened. The telemetry isn’t lost because something broke; it was sampled out, and sampling gets more aggressive precisely when things are busiest. Which is when you need it.

If your run is that noisy, look at samplingSettings in host.json before you trust the alert. Raising maxTelemetryItemsPerSecond or excluding types from sampling is a one-line change, and the Azure Functions monitoring docs spell out the trade-off. The uncomfortable part is that an alert built on sampled data fails silently: you don’t get a wrong answer, you get no answer, which looks identical to nothing having gone wrong.

Gotchas

• Failed is not the only bad ending. An orchestration stuck in Running never emits a Failed event, so this alert says nothing about it. With retries nested inside HTTP-level retries, a single activity can hold a run open for a long time and look perfectly healthy. If that’s a risk for you, a second alert on orchestration duration is the companion piece.
• Alert on the orchestrator, not the activity. I cannot stress this one enough. Drop the functionType filter and your retry policy becomes a mailing list. Every attempt under CallActivityWithRetryAsync (or CallActivityAsync with retry options) logs its own Failed event, so one healthy orchestration that recovers on attempt four has already emitted three of them.
• isReplay is not optional. Replay is normal behaviour, not a fault, and the same lifecycle event can show up more than once without that filter.
• A threshold of zero only works if failures are rare. Mine are. If yours are routine, raise the threshold and treat the alert as a rate detector instead, or you’ll train yourself to archive the mail unread.
• The alert is detection, not remediation. Getting the mail is step one. Knowing what to do with a Failed instance, and whether a rerun is safe, is a separate problem that idempotent activities exist to make answerable.

Wrapping Up

A failed Durable Functions orchestration is loud in the storage table and silent everywhere a human looks. The Durable extension already logs every lifecycle transition to Application Insights, so the cheapest possible monitor is a KQL query over traces filtered to non-replay orchestrator events in state Failed, wired to an action group you already own. Rule of thumb: before you write a watchdog, check whether the thing you want to watch is already logging it. Mine was, and the difference between knowing and not knowing cost me $1.50 a month.

New to this corner of Azure? Durable Functions: A Function That Sleeps for a Week is where the rest of this series starts.

That kind of library is exactly the moment to pick your foundation on purpose. So I sat down and looked hard at PnP Core.

And then I stayed on PnP.Framework.

What Makes PnP Core Tempting

The thing I actually want from PnP Core isn’t a feature. It’s that somebody already made a decision I keep having to make myself.

With CSOM and raw calls, every time I read something out of SharePoint I have to think about how: SharePoint REST, or Microsoft Graph? Which one has this property? Which one is faster here? PnP Core removes that question. Per the docs, the SDK “by default is configured to favor the Microsoft Graph API when you’re reading SharePoint data assuming the requested properties are available via Graph”, and it falls back to SharePoint REST when they aren’t. If you disagree, you flip GraphFirst to false on the PnPContext and it prefers REST instead.

Someone with more context than me picked the better call per operation, and I get to write the intent instead of the plumbing. Add async-first, a real domain model, and modern .NET hosting, and it’s not a close comparison on paper.

The problem is that my code doesn’t run on paper.

Blocker 1: The Provisioning Engine Isn’t There

Almost everything I build for SharePoint eventually provisions something. Lists, content types, pages, navigation. That’s ApplyProvisioningTemplate, and it lives in PnP.Framework. PnP Core has no provisioning engine.

So a migration wasn’t “rewrite my queries”. It was “rewrite my queries and keep PnP.Framework around anyway for the part that does the heavy lifting”. Two SDKs, two mental models, no win.

That’s the part I’d already made peace with, until pnpframework issue #1237 showed up in June: a roadmap for moving both the Provisioning Engine and the Modernization Engine into PnP Core as dedicated projects, with the PnP.Framework versions deprecated afterwards. Target is Q4 2026.

That single issue turns my biggest objection into a waiting game. I don’t need PnP Core to grow a provisioning engine as a favor to me. It’s on the roadmap, in the open, with a phase 2 already referenced for the wider PnP.Framework deprecation. Everything I’ve written about splitting templates into modular files for retry resilience survives that move, because it’s a property of how you structure templates, not of which SDK applies them.

Blocker 2: CAML Joins Come Back Empty

The second one I couldn’t wait out, because it’s the query pattern I lean on hardest.

SharePoint’s CAML supports joining lists and pulling fields across the join with <Joins> and <ProjectedFields>. It’s the difference between one query and four, and I’ve written a whole post on doing it with CAMLEX in CSOM because it saves resource units and spares you from merging rows in C#.

Run that same view XML through PnP Core’s LoadItemsByCamlQueryAsync and nothing breaks. No exception, no error, no warning. You get items back, the join is honored for filtering, and the projected fields simply aren’t in the result. The REST GetItems endpoint doesn’t serialize them, so they never make it into the response for the SDK to map.

A silent hole in the data is worse than a thrown exception, and it’s a hole in the one query shape I most wanted to keep.

So I filed issue #1799 and then PR #1802 with an implementation: two new methods on IList that run the query through CSOM’s List.GetItems(CamlQuery) instead of REST, because CSOM does return projected fields.

/// <summary>
/// Loads list items based up on a CAML query executed via CSOM, which also returns
/// fields projected from a joined list (CAML Joins/ProjectedFields)
/// </summary>
public Task<ICamlQueryCsomResult> LoadItemsByCamlQueryViaCsomAsync(CamlQueryOptions queryOptions);

public ICamlQueryCsomResult LoadItemsByCamlQueryViaCsom(CamlQueryOptions queryOptions);

Using it looks like any other PnP Core call. This is the shape from the integration test in the PR:

var page1 = await list.LoadItemsByCamlQueryViaCsomAsync(new CamlQueryOptions()
{
    ViewXml = viewXml,
    DatesInUtc = true
});

var firstItem = page1.Items[0];
var projected = firstItem["ProjectedText"] as IFieldLookupValue;
Console.WriteLine(projected.LookupValue);

// Next page, without hand-building a paging string
var page2 = await list.LoadItemsByCamlQueryViaCsomAsync(new CamlQueryOptions()
{
    ViewXml = viewXml,
    DatesInUtc = true,
    PagingInfo = page1.PagingInfo
});

What’s happening here?

1. LoadItemsByCamlQueryViaCsomAsync takes the exact same CamlQueryOptions as the REST-based method, so the view XML with <Joins> and <ProjectedFields> is unchanged. Only the transport differs.
2. The projected field comes back typed as an IFieldLookupValue, not as a raw string. That’s how CSOM represents it and it’s what you’d expect from a lookup coming across a join, so LookupId and LookupValue are both there.
3. The returned ICamlQueryCsomResult carries Items plus PagingInfo, taken from CSOM’s ListItemCollectionPosition. Feed PagingInfo back into the next call and you get the next page. It’s null when there are no more pages.
4. The loaded items are also merged into the list’s Items collection, the same as the existing CAML methods, so nothing about the surrounding model changes.

Gotchas

• The failure mode is silence, not an error. No exception on a join query with projected fields means your code happily maps a null and moves on. If you’re evaluating PnP Core for join-heavy work, assert on the projected value in a test, don’t eyeball the item count.
• A roadmap is a plan, not a shipped release. Issue #1237 has a Q4 2026 target and it’s still open. Same for my PR: open, no reviewer assigned yet. I’m building on the current state of both SDKs, not on the version I hope exists in six months.
• No batch variant for the CSOM path, on purpose. The items are materialized immediately, so it doesn’t fit PnP Core’s batching model. If you’re used to queueing everything into a batch, this one call stands apart.
• Deprecation warnings are part of the plan. Once the engines land in PnP Core, the PnP.Framework equivalents get marked deprecated and stop taking new features. So if you’re searching for whether PnP.Framework is deprecated and whether the provisioning engine is moving to PnP Core: yes and yes, on a published roadmap, and the two blockers above are what stand between “announced” and “usable”. Staying put is a decision with an expiry date, which is exactly why I’d rather have the blockers resolved than keep postponing.

Wrapping Up

I’m not avoiding PnP Core because I prefer PnP.Framework. I’m on PnP.Framework because two specific things weren’t there: the provisioning engine, and CAML joins that actually return the joined data. Both now have an issue number attached, and one of them has my name on the pull request.

Rule of thumb: pick the SDK by what your workload actually needs today, then go make the gap smaller instead of waiting for someone else to. Filing #1799 took an evening. It moved my migration date more than another month of reading release notes would have.

When the provisioning engine lands in PnP Core and projected fields come back from a join, I’m switching and I’m not looking back.

The first time step seven failed, I got to watch my engine try to create a site that already existed.

That run taught me the rule this post is about: in a long provisioning flow, you don’t roll back when something fails. You checkpoint, and you resume forward.

If Durable Functions are new to you, start with my intro to what they are and what they can do - this post builds on it.

Why Rollback Is the Wrong Instinct

When provisioning fails at step seven, you have a half-built site. The textbook answer is a compensation saga: undo steps six through one in reverse order. Delete the folders, detach the template, deactivate the features, delete the site, then recreate everything from scratch on the next attempt.

I started sketching that and stopped halfway through the list, because every line was either dangerous or absurd. Deleting a site collection to work around a failed navigation tweak is using a crane to hang a picture. And some steps don’t even have an undo - you can’t meaningfully “unapply” a provisioning template that merged fields into existing lists.

Here’s the thing rollback ignores: the six completed steps aren’t damage. They’re progress. The site is fine; what’s missing is the steps that haven’t run yet. So the only recovery that makes sense is forward: figure out where the run stopped, and continue from there.

That reframes the problem completely. I don’t need compensation logic. I need to know, reliably, which steps finished.

Carry the Progress in the State

Durable Functions makes this natural, because an orchestrator already passes state to each activity and gets state back. The trick is to make “what’s done” part of that state. My orchestration state looks something like this:

public sealed record SiteSetupState(
    string CustomerId,
    string SiteUrl,
    string[] CompletedSteps
);

And the orchestrator walks its steps like this:

var state = context.GetInput<SiteSetupState>() ?? await CreateSite(context, customerId);

string[] pipeline =
[
    nameof(ActivateFeatures),
    nameof(ApplyTemplate),
    nameof(SeedFolders),
    nameof(AddMemberGroups),
    nameof(RegisterSite),
];

foreach (var step in pipeline)
{
    if (state.CompletedSteps.Contains(step))
    {
        logger.LogInformation("{Step} already completed, skipping.", step);
        continue;
    }

    await context.CallActivityAsync(step, state, retryOptions);

    state = state with { CompletedSteps = [.. state.CompletedSteps, step] };
    context.SetCustomStatus(state);
}

What’s happening here?

1. The pipeline is just an ordered list of activity names. Nothing clever, and that’s the point - the interesting machinery is around the calls, not in them.
2. Before each step, the orchestrator checks whether this step already ran. On a fresh run the array is empty and nothing is skipped. On a resumed run, this check is what fast-forwards past the finished work.
3. After each successful step, the state is copied with the step name appended. An immutable with copy, so nothing mutates in place, which keeps replays honest.
4. SetCustomStatus publishes the updated state on the orchestration instance. This is the checkpoint. It costs one line.

That last line is doing more work than it looks like. Custom status is readable from outside the orchestration - through the management API, without touching the orchestration history. So the same call gives you two things: anyone polling the instance sees live progress (“three of six steps done”), and if the run fails, the last published state is sitting right there, telling you exactly where it stopped.

Resume Is Just Input

Because the checkpoint is a plain serializable record, resuming a failed run doesn’t need any special framework support. You read the failed instance’s custom status, and you start a new orchestration with that state as input:

var failed = await client.GetInstanceAsync(failedInstanceId, getInputsAndOutputs: true);
var checkpoint = failed.ReadCustomStatusAs<SiteSetupState>();

await client.ScheduleNewOrchestrationInstanceAsync(
    nameof(SiteSetupOrchestrator),
    checkpoint);

The new run enters the same loop, finds five steps in CompletedSteps, skips them in about a millisecond, and picks up at step six. No site deletion, no re-creation, no duplicate template apply. The half-built site becomes a five-sixths-built site, then a finished one.

I like how little there is to this. The “resume feature” is the skip-check in the loop plus the fact that the input type and the checkpoint type are the same type. That’s it.

The Gap That Idempotency Covers

One honest caveat. The checkpoint is written after the activity succeeds, so there’s a window: the activity finishes, the process dies before the checkpoint lands. On resume, that step’s name isn’t in CompletedSteps, and it runs again.

You can’t close that window - it’s inherent to doing the work and recording the work as two operations. What you do instead is make every activity safe to run twice: check before create, treat “already exists” as success, write with upserts. That’s a full topic on its own, but the division of labor is worth stating plainly: the checkpoint decides how often steps rerun, idempotency decides whether reruns hurt. You need both. The checkpoint alone has a crash window; idempotency alone means re-executing ten minutes of finished work on every hiccup.

And never checkpoint before the call to close the window from the other side - then a crashed step gets skipped on resume, which is far worse. A step that runs twice is a wasted minute; a step that runs zero times is a broken site that says “Completed”. Ask me how I know.

Gotchas

• Use the replay-safe logger. Orchestrator code replays from history every time the instance wakes up. context.CreateReplaySafeLogger(...) keeps your logs from repeating every completed step on each replay. A regular ILogger in an orchestrator will gaslight you.
• No clocks, no GUIDs in the orchestrator. DateTime.UtcNow, Guid.NewGuid(), and Random produce different values on replay and corrupt the history. Anything nondeterministic belongs inside an activity, including generated names and timestamps you want in the state.
• Custom status has a size limit (16 KB of JSON). A record with a customer ID, a URL, and an array of step names fits hundreds of times over, but don’t stuff a whole template or file manifest in there. Checkpoint the position, not the payload.
• Step names are a contract. The moment CompletedSteps is persisted anywhere - a failed instance you might resume next week - renaming an activity breaks the match and the step silently reruns (fine, if idempotent) or the resume misbehaves (not fine). Rename with the same care you’d give a database column.
• Report progress somewhere humans look. Custom status is great for machines; my engine also writes the current step name to a status column in the site inventory list, inside a try/catch that logs and swallows. A cosmetic status write must never kill a provisioning run.

Wrapping Up

Long provisioning flows fail in the middle, so design for resuming instead of undoing: carry a list of completed steps in the orchestration state, publish it as custom status after every step, skip completed steps on rerun, and feed the saved state back in to resume. Rollback is for databases. Provisioning goes forward.

When building automated site provisioning, every Microsoft 365 group creation triggers a welcome email to each member by default. In an automated scenario where multiple groups are created at once, that quickly turns into a flood of emails your users didn’t ask for — and they’re going to call it spam.

Microsoft documents WelcomeEmailDisabled as a supported option, but doesn’t show you how to actually set it from the Graph SDK in C#. That’s what this post is about.

The Weird Part: AdditionalData

If you look at the typed Group object in the SDK, you won’t find a ResourceBehaviorOptions property anywhere. It has to be set through AdditionalData — a catch-all dictionary for properties that exist in the Graph API but aren’t modeled as first-class typed properties in the SDK.

It works fine, but it does mean you lose IntelliSense and compile-time safety. The same pattern applies to owners@odata.bind and members@odata.bind, which let you assign owners and members at creation time without separate follow-up calls.

The Solution

Here’s the complete group creation request with welcome emails disabled, owners set, and members added — all in a single API call:

var ownerId = $"https://graph.microsoft.com/v1.0/users/{ownerObjectId}";
var groupMembers = new List<string>
{
    $"https://graph.microsoft.com/v1.0/users/{memberObjectId1}",
    $"https://graph.microsoft.com/v1.0/users/{memberObjectId2}"
};

Group requestBody = new()
{
    Description = description,
    DisplayName = displayName,
    GroupTypes = ["Unified"],
    MailEnabled = false,
    MailNickname = siteName,
    SecurityEnabled = true,
    AdditionalData = new Dictionary<string, object>
    {
        { "resourceBehaviorOptions", new List<string> { "WelcomeEmailDisabled" } },
        { "owners@odata.bind", new List<string> { ownerId } },
        { "members@odata.bind", groupMembers }
    }
};

Group? group = await _graphClient.Groups.PostAsync(requestBody);

resourceBehaviorOptions

resourceBehaviorOptions controls specific group behaviors at creation. WelcomeEmailDisabled simply stops Microsoft 365 from sending the welcome email to members.

You can also combine multiple options in the same list if needed:

{ "resourceBehaviorOptions", new List<string> { "WelcomeEmailDisabled", "HideGroupInOutlook" } }

Other supported values are documented here.

owners@odata.bind and members@odata.bind

The @odata.bind syntax binds users to the group by their full resource URL at creation time, so you don’t need separate POST /groups/{id}/members calls afterward. The URL format must be the full Graph v1.0 path:

https://graph.microsoft.com/v1.0/users/{objectId}

We’ve all tried creating a SharePoint list without using Content Types from the start. It seems like the quick solution, but it can lead to challenges later when restructuring the list. This post explains why using Content Types from the beginning is a smart move that can save time and hassle in the long run.

This has been a recurring issue for me 😅 – countless times I’ve started a SharePoint list without Content Types, only to realize later that I needed the list for tasks like search 🔍 or advanced filtering. And, of course, it usually happens when the list is already full of data 📊 without any associated Content Type, making it even more challenging 🛠️ to get everything to work smoothly.

⚠️ Disclaimer: This will only work if the columns in the Content Type match those already present in the list.

How Do I Fix It? 🤔

The first step is, of course, to create a content type. Once it’s created, I then export it as a template using the PnP PowerShell command Get-PnPSiteTemplate 💻. I make sure that only the content type is included in the XML file 📂.

Once the PnP template is ready, a PowerShell script I created can be used to fix this issue – though it can’t handle all scenarios. The script includes the following variables, which need to be filled out:

$siteUrl = "https://xxx.sharepoint.com/sites/xxx"
$listName = ""
$contentTypeName = ""
$columnsToMap = @("...")  # Replace with the actual column names
$userFields = @("...")  # Replace with actual user field names if needed
$templatePath = "..\ContentTypeTemplate.xml";

What the script does is fairly simple 🛠️ – I load all rows with their values into memory 🧠, remove the columns ($columnsToMap) that need to be deleted 🗑️, then invoke the PnP template containing the content type. Finally, I reload all values into the new columns. Since they have the same names as the old columns, everything loads smoothly ✅.

# Connect to SharePoint Online
Connect-PnPOnline -Url $siteUrl -Interactive

# Enable content type management on the list
Set-PnPList -Identity $listName -EnableContentTypes $true
Write-Host "Content types enabled on the list."

# Backup data from old columns
$items = Get-PnPListItem -List $listName -PageSize 2000
$backupData = @{}

foreach ($item in $items) {
    $itemData = @{}
    # Backup old column data
    foreach ($column in $columnsToMap) {
        $itemData[$column] = $item[$column]
    }
    $backupData[$item.Id] = $itemData
}

# Remove old columns
foreach ($column in $columnsToMap) {
    Remove-PnPField -List $listName -Identity $column -Force
    Write-Host "Removed old column:" $column
}

# Apply PnP Provisioning Template
Invoke-PnPSiteTemplate -Path $templatePath
Write-Host "PnP template applied to the site."

# Get the content type
$contentType = Get-PnPContentType -Identity $contentTypeName

# Add the content type to the list
Add-PnPContentTypeToList -List $listName -ContentType $contentType
Write-Host "Content type added to the list."

# Update items to the new content type and restore data to new columns
foreach ($item in $items) {
    $itemId = $item.Id
    $itemData = $backupData[$itemId]
    
    # Handle user fields
    foreach ($userField in $userFields) {
        if ($itemData[$userField]) {
            $UserDto = $itemData[$userField];
            write-host "User: " $UserDto.Email

            $itemData[$userField] = $UserDto.Email
        }
    }

    # Update item content type
    Set-PnPListItem -List $listName -Identity $itemId -Values @{"ContentTypeId" = $contentType.Id }
    
    # Restore data to new columns
    Set-PnPListItem -List $listName -Identity $itemId -Values $itemData
    Write-Host "Updated item ID:" $itemId
}

Write-Host "All items updated to the new content type and old columns removed."

# Disconnect from SharePoint Online
Disconnect-PnPOnline

As mentioned earlier, this script doesn’t solve everything. For example, any views created with the old columns will no longer work, even if the new columns have the same name. So, there’s definitely room for improvement in my script.

That said, the script has saved me quite a bit of manual work multiple times 🙌.