LCS is going away.

If you haven't heard that yet, now you have - not that Microsoft has been trying to hide it. Microsoft is moving all of F&O environment management into the Power Platform Admin Center, or PPAC. Starting January 2026, all new F&O implementations have to go through PPAC. That's the direction and it's not changing. Let's review what that actually means for two things that matter a lot in day-to-day operations: the new capacity model and the ability to run more than one production environment per tenant.

LCS to PPAC: What's Actually Happening

For a long time, F&O lived in LCS. That was where you deployed environments, applied updates, handled support tickets. It was its own world. PPAC is where everything else - Power Apps, Customer Engagement, Power Automate - already lived. Microsoft's goal is to get it all under one roof. That's the One Dynamics One Platform strategy, or ODOP if you like acronyms.

The deprecation of LCS has been happening in stages. System Diagnostics went away in September 2024. More features have been removed since. If you're still doing everything in LCS, you're going to want to start paying attention to this because the migration is going to happen one way or another. Microsoft provided manual migration options in January 2025 and automated migration tools in April 2025. If you haven't started testing migration in sandbox environments yet, that's the place to start.

The upside is that PPAC gives you a single place to manage everything. Finance, Supply Chain, Power Apps, CRM - all of it in one admin view. Consistent security policies, consistent license governance. It's genuinely better once you're through the transition and learn the new tools.

The New Capacity-Based Storage Model

This is one of the bigger operational changes to understand. In PPAC, storage isn't tied to a specific environment tier the way it was in LCS. Instead, your tenant gets a pooled entitlement and environments draw from that. The storage is split into three types.

Database

Your core ERP tables and relational records. This is where most of your transactional data lives.

File

Attachments, annotations, images. Microsoft has been migrating data here from database storage, so you may see database shrink and file grow over time. It depends on your setup. I'd also recommend looking at SharePoint for storage as that is a potentially cheaper option.

Log

Audit logs, plug-in trace logs, elastic table data. This one tends to grow quietly over time in compliance-heavy environments.

Here's the important part: each type is tracked separately. Being over in one type puts you in overage even if you have plenty of room in the others. You can't use excess file storage to cover a database deficit, for example. Keep that in mind when you're monitoring.

Where Your Entitlement Comes From

Your total storage entitlement is built up from three sources:

Tenant default - base capacity you get at sign-up
User licenses - each user license you purchase adds a bit more capacity to the pool
Add-on storage - additional capacity purchased separately if you need more
You can see the full breakdown in PPAC under Licensing > Capacity Add-ons > Summary. Worth pulling up if you haven't looked at it yet.

Pooled vs. Pre-Allocated

By default, all environments just pull from the shared tenant pool. That works fine until you have multiple environments competing for the same capacity. You can get ahead of that by pre-allocating specific amounts of database, file, and log capacity to individual environments. Pre-allocated capacity gets deducted from the tenant pool, so it's reserved for that environment and other environments can't touch it.

You do this in PPAC under Licensing > Dataverse > Manage Capacity. If you're running production environments for different business units, this is how you make sure one environment's growth doesn't impact another.

Pay-As-You-Go

If you'd rather not manage hard capacity limits, you can link an environment to an Azure subscription and let overage get billed through pay-as-you-go. Operations don't get blocked, overages just get charged to the subscription. Useful for environments with unpredictable growth but can be pricey if not actively managed. If you're using Pay-As-You-Go, PAYG, constantly you should consider just purchasing additional storage capacity.

What Happens When You Go Over

This is the part that will cause problems if you're not watching. PPAC has three notification thresholds and then enforcement kicks in.

15% remaining - first warning email goes out to tenant admins, weekly
5% remaining - second warning; admin operations are at risk
0% in overage - key operations get blocked until you resolve it
When you hit overage, these operations stop working:

• Creating a new environment
• Copying an environment
• Restoring from backup
• Converting a trial to production
• Recovering a deleted environment
• Adding a Dataverse database to an environment

That's a list that can really hurt you if it happens at the wrong time. The notifications go out weekly to tenant admins, Power Platform admins, and Dynamics 365 admins. You can't opt out of them and you can't delegate them to someone else, so make sure the right people have the right admin roles.

Multiple Production Environments

This is a big one. Under LCS, each LCS project got one production environment. That was it. If you needed two production environments in the same tenant - too bad. Not an option.

In PPAC, that limit is gone. You can create as many production environments as you need, as long as you have the capacity and licenses to support them. They all show up in a single view in PPAC.

A note on data separation: legal entities handle most data isolation scenarios in F&O. However, global tables exist across all legal entities in the same environment. If you have a requirement for strict global table isolation between business units, multiple environments is the way to do it.

LCS vs. PPAC: Side by Side

When Would You Actually Use This

Here are the scenarios where running more than one production environment actually makes sense:

• Strict data separation between business units - where legal, regulatory, or security requirements mean you can't share global tables
• Multi-region deployments - production environments in different Azure regions to meet data residency requirements
• Acquired companies or subsidiaries - an entity you've acquired that runs its own F&O instance and needs to stay independent
• Complex go-live transitions - keeping a stable production environment running while a new one is cut over

What This Means for Licenses

This is worth being clear on. Multiple production environments doesn't mean multiple license costs per user. Licenses are counted at the tenant level. A user with access to two production environments consumes one license, not two. We now check that the Entra account has the license (or will in the very near future).

What you will see is that each environment shows its own role assignments and license requirements when you look at it individually. When you pull the tenant-level view, it consolidates all of that. So if a user needs Finance in one environment and Supply Chain Management in another, PPAC will show both requirements rolled up at the tenant level. That's actually useful for licence auditing once you get used to the view.

Where to Start

If you're planning a migration or trying to get a handle on what PPAC means for your environment strategy, here's a reasonable order of operations.

Check your current storage consumption

Go to Licensing > Capacity Add-ons in PPAC. Look at database, file, and log at both tenant and environment level. Know where you stand before anything else.

Audit your LCS project structure

Do you actually need all those separate projects or were they created out of LCS convention? PPAC's unified view might let you simplify. Or you might find you need more production environments than you currently have. Either way, now's the time to think about it.

Pre-allocate capacity where it matters

For any production environment - especially if you're going to have more than one - consider pre-allocating capacity. It prevents one environment's growth from blocking operations in another.

Pilot the migration in sandbox first

Don't go straight to production. Use the automated Copy Environment – Everything feature on a sandbox to validate the process. For non-production environments, transaction-less copies can cut storage use by up to 90% and are worth using where possible.

Get your admin team up to speed on PPAC

The tooling is different. PAC CLI, Power Platform build tools, Azure DevOps pipelines - this is the new stack for F&O admins. If your team is still LCS-first, that's where the training investment needs to go.

Summary

The capacity model in PPAC is fairly straightforward once you understand that the three storage types are tracked independently and that overage in any one of them blocks operations. Keep an eye on the thresholds, pre-allocate for production environments, and know that pay-as-you-go is an option if you'd rather not manage hard limits.

The multiple production environments change is the one that will matter most for organizations that were previously working around the one-production-per-LCS-project constraint. That constraint is gone. You can now structure your environments to match your actual business requirements rather than working within what LCS allowed. That's a good thing.