Applications often need to display multiple views on the same screen, so efficient space management is key to the user experience. Navigation panels, data grids, and document previews may each require different amounts of space depending on the task. Fixed layouts can limit this flexibility, and implementing interactive resizing can require additional code.

The Syncfusion .NET MAUI Grid Splitter, introduced in Essential Studio 2026 Volume 3, provides built-in support for resizing, collapsing, and expanding panes.

Let’s explore its features and build a sample employee profile layout.

Key features of the .NET MAUI Grid Splitter

The Syncfusion .NET MAUI Grid Splitter provides several capabilities for building multi-pane interfaces:

• Resizable panes: Let users adjust the space allocated to different content areas.
• Collapsible panes: Allow users to hide and restore panels when needed.
• Horizontal and vertical orientations: Arrange panes side by side or vertically.
• Flexible pane sizing: Set initial sizes and define resizing limits.
• Customizable separators: Adjust the separator’s appearance.
• Nested splitters: Create layouts with multiple independently resizable sections.

Let’s look at how to use these features in an application.

Resize and collapse panes

Some applications need users to control how much space different content areas occupy. For example, users might want to widen a navigation panel to read longer item names or expand a document preview to inspect its contents.

The .NET MAUI Grid Splitter lets users drag a separator to resize adjacent panes at runtime. It handles the resizing logic automatically, reducing development effort and simplifying layout management.

You can also set the MinimumSize and MaximumSize properties of SplitterPane to define resizing limits. These limits keep each pane usable while still allowing users to adjust the layout.

Sometimes, resizing isn’t enough. Users may want to hide a panel completely to focus on their primary task. The Grid Splitter supports collapsible panes, allowing users to quickly hide or restore content and focus on the information that matters most.

This is useful for navigation panels, property windows, report filters, and contextual tool panels.

Customize the splitter separator

The separator shows users where they can resize panels. You can customize its appearance to match your application’s design.

The Grid Splitter provides properties such as:

• SeparatorSize: Sets the separator’s thickness.
• SeparatorBackground: Sets the separator’s background color.

For example, the following XAML configures a horizontal splitter with a customized separator:

<gridSplitter:SfGridSplitter
    Orientation="Horizontal"
    SeparatorSize="8"
    SeparatorBackground="#E0E0E0">

    <gridSplitter:SplitterPane Size="1*">
        <Label Text="Navigation"
               HorizontalTextAlignment="Center"
               VerticalTextAlignment="Center" />
    </gridSplitter:SplitterPane>

    <gridSplitter:SplitterPane Size="2*">
        <Label Text="Main Content"
               HorizontalTextAlignment="Center"
               VerticalTextAlignment="Center" />
    </gridSplitter:SplitterPane>

</gridSplitter:SfGridSplitter>

Here, the separator is 8 units thick and uses a light-gray background. Adjust these values to suit your application’s visual style.

Configure pane sizes

Different application regions often need different amounts of space. A navigation panel may need less room than a document editor, while a details panel needs enough space to display its content.

The Size property of SplitterPane defines its initial size and how space is distributed among panes.

For example, panes with sizes 1*, 2*, and 1* start with a proportional size ratio of 1:2:1.

You can combine Size with MinimumSize and MaximumSize to control how far users can resize each pane:

<gridSplitter:SfGridSplitter Orientation="Horizontal">

    <gridSplitter:SplitterPane
        Size="1*"
        MinimumSize="120"
        MaximumSize="250">

        <Label Text="Navigation Pane"
               HorizontalTextAlignment="Center"
               VerticalTextAlignment="Center" />
    </gridSplitter:SplitterPane>

    <gridSplitter:SplitterPane
        Size="2*"
        MinimumSize="250">

        <Label Text="Main Content"
               HorizontalTextAlignment="Center"
               VerticalTextAlignment="Center" />
    </gridSplitter:SplitterPane>

    <gridSplitter:SplitterPane
        Size="1*"
        MinimumSize="150"
        MaximumSize="350">

        <Label Text="Details Pane"
               HorizontalTextAlignment="Center"
               VerticalTextAlignment="Center" />
    </gridSplitter:SplitterPane>

</gridSplitter:SfGridSplitter>

In this example, the navigation pane has a minimum size of 120 units and a maximum of 250 units. The details pane can range from 150 to 350 units.

These limits help prevent panels from becoming too small or taking up too much space. The final pane size depends on available space, pane constraints, and the sizes of neighboring panes.

Choose horizontal or vertical layouts

The Orientation property determines how panes are arranged and which dimension changes during resizing.

• Horizontal: Arranges panes side by side. Dragging the separator adjusts their width.
• Vertical: Arranges panes from top to bottom. Dragging the separator adjusts their height.

You can combine both orientations to create layouts suited to your application. For example, a horizontal splitter can separate a navigation panel from an editor, while a vertical splitter can divide the editor from an output panel.

Build nested layouts in .NET MAUI

A simple two-pane layout may be enough for some applications. However, enterprise applications often need several independently resizable regions.

Consider an employee management application with profile details, skills, contact information, and an employee summary. Nested Grid Splitters help organize multiple content regions while keeping the layout modular, maintainable, and easy to resize.

Let’s build this interface with XAML.

Quick example: Building an employee profile layout

This example creates three panes at the top of the screen and an employee summary at the bottom. Users can resize the top and bottom sections, as well as the panes within the top section.

Step 1: Create a project and install the package

Create a .NET MAUI application in Visual Studio. Install the Syncfusion.Maui.GridSplitter NuGet package using the NuGet Package Manager or the .NET CLI:

dotnet add package Syncfusion.Maui.GridSplitter

Use a package version compatible with your .NET MAUI project.

Step 2: Register Syncfusion core

In MauiProgram.cs, register the Syncfusion Core handler:

using Syncfusion.Maui.Core.Hosting;

public static class MauiProgram
{
    public static MauiApp CreateMauiApp()
    {
        var builder = MauiApp.CreateBuilder();

        builder.ConfigureSyncfusionCore();

        return builder.Build();
    }
}

Keep any existing application configuration and service registrations in this method.

Step 3: Add the Grid Splitter to your XAML page

Declare the Grid Splitter namespace in your page:

xmlns:gridSplitter="clr-namespace:Syncfusion.Maui.GridSplitter;assembly=Syncfusion.Maui.GridSplitter"

Add the following layout inside the page’s content:

<gridSplitter:SfGridSplitter
    Orientation="Vertical"
    HeightRequest="600">

    <!-- Top section -->
    <gridSplitter:SplitterPane Size="2*">

        <gridSplitter:SfGridSplitter
            Orientation="Horizontal">

            <!-- Profile pane -->
            <gridSplitter:SplitterPane
                Size="1*"
                MinimumSize="180"
                IsCollapsible="True">

                <VerticalStackLayout Padding="15" Spacing="8">
                    <Label Text="Profile"
                           FontSize="18"
                           FontAttributes="Bold" />

                    <Label Text="Name" FontAttributes="Bold" />
                    <Label Text="Alex Johnson" />

                    <Label Text="Role" FontAttributes="Bold" />
                    <Label Text="Senior Developer" />

                    <Label Text="Experience" FontAttributes="Bold" />
                    <Label Text="8 years" />
                </VerticalStackLayout>

            </gridSplitter:SplitterPane>

            <!-- Skills pane -->
            <gridSplitter:SplitterPane
                Size="2*"
                MinimumSize="180"
                IsCollapsible="True">

                <VerticalStackLayout Padding="15" Spacing="8">
                    <Label Text="Skills"
                           FontSize="18"
                           FontAttributes="Bold" />

                    <Label Text=".NET MAUI" />
                    <Label Text="C#" />
                    <Label Text="XAML" />
                    <Label Text="MVVM" />
                    <Label Text="Syncfusion Controls" />
                </VerticalStackLayout>

            </gridSplitter:SplitterPane>

            <!-- Contact pane -->
            <gridSplitter:SplitterPane
                Size="1.5*"
                MinimumSize="180"
                IsCollapsible="True">

                <VerticalStackLayout Padding="15" Spacing="8">
                    <Label Text="Contact"
                           FontSize="18"
                           FontAttributes="Bold" />

                    <Label Text="Email" FontAttributes="Bold" />
                    <Label Text="alex@example.com" />

                    <Label Text="Phone" FontAttributes="Bold" />
                    <Label Text="+1 987 654 3210" />

                    <Label Text="Location" FontAttributes="Bold" />
                    <Label Text="Seattle, WA" />
                </VerticalStackLayout>

            </gridSplitter:SplitterPane>

        </gridSplitter:SfGridSplitter>

    </gridSplitter:SplitterPane>

    <!-- Bottom section -->
    <gridSplitter:SplitterPane Size="1.5*">

        <VerticalStackLayout Padding="20" Spacing="10">
            <Label Text="Employee Summary"
                   FontSize="18"
                   FontAttributes="Bold" />

            <Label Text="Alex Johnson" FontAttributes="Bold" />
            <Label Text="Senior Developer" />
            <Label Text="Skills: .NET MAUI, C#, XAML, MVVM" />
        </VerticalStackLayout>

    </gridSplitter:SplitterPane>

</gridSplitter:SfGridSplitter>

How the example works

The outer SfGridSplitter uses vertical orientation to divide the layout into top and bottom sections. The top section contains a nested SfGridSplitter that arranges the Profile, Skills, and Contact panes side by side.

The following properties control the layout:

• Orientation: Determines how panes are arranged.
• Size: Defines the initial size and proportional distribution of panes.
• MinimumSize: Sets the minimum size of a pane.
• IsCollapsible: Allows users to hide and restore a pane.

Users can resize the sections and collapse individual panes to make more room for other content. You can also add data grids, charts, document previews, or other .NET MAUI views to these panes.

Common use cases

The .NET MAUI Grid Splitter is useful for applications that display multiple content areas at once.

Supercharge your cross-platform apps with Syncfusion's robust .NET MAUI controls.

Try It Free

Conclusion

The Syncfusion .NET MAUI Grid Splitter makes it easier to build layouts with resizable and collapsible panes. With support for different orientations, configurable pane sizes, customizable separators, and nested splitters, you can organize complex interfaces without implementing the core resizing behavior yourself.

Explore the Grid Splitter in Essential Studio 2026 Volume 3 and try the available GitHub samples. Existing customers can download the latest version from the License and Downloads page, while new users can start with a 30-day free trial.

For questions or assistance, visit the Syncfusion support forums, support portal, or feedback portal.

Scan it to get the demo app.

Scan it to get the demo app.

Scan it to get the demo app.

A third suggestion from Luca Bacci on creating a fake agile wrapper that is technically agile but is not useful outside its home apartment was to use the COM static store.

The COM static store doesn’t help us, because the COM static store runs down when the last thread shuts down COM, whereas we want something that runs down when a single apartment shuts down COM.

There is a per-apartment version of the COM static store, but it is part of the Core­Application­View, which is (1) something that only UWP programs have, and (2) exists only for apartments that have a core application view, and those are restricted to single-threaded apartments.

Even if there were a per-apartment static store, putting something into it would require generating a unique name and remembering it for later removal. You could probably use the stringified address of the object, with a fixed GUID prefix as a pseudo-namespace. Since we’re dealing with a dictionary, the insertion and removal operations are going to be O(log n) or O(1), depending on the implementation, but even the constant-time version will have a higher constant than a single index lookup in the Global Interface Table.

The post Why didn’t we use the COM static store to clean up the unmarshalable delegate? appeared first on The Old New Thing.

The quickest way to discover what you do not understand is to volunteer to explain it. Everything makes sense while you are reading. The diagram looks logical. The demo works. You recognize the terminology. You close the browser feeling reasonably confident. Then someone asks: “Why?”

And suddenly, that confidence has a few dependencies you forgot to install. That is why I believe in learning out loud. Across engineering, open source, mentoring and community work, teaching belongs inside the learning process. Waiting until you know everything before sharing anything is a very effective way to stay quiet forever.

𝗧𝗲𝗮𝗰𝗵𝗶𝗻𝗴 𝗶𝘀 𝗹𝗲𝗮𝗿𝗻𝗶𝗻𝗴 𝘄𝗶𝘁𝗵 𝘁𝗵𝗲 𝗹𝗶𝗴𝗵𝘁𝘀 𝗼𝗻.

It makes the assumptions visible. Including your own. We can carry a surprising amount of half-understood knowledge around in our heads. Familiarity is comfortable. We have seen the pattern before. We know which words belong in the conversation. We can probably follow someone else’s explanation. Building our own explanation asks more of us.

Where do I start? What does the other person already know? Which detail actually matters? What happens when the example stops working? Those questions force us to organize what we know and confront what we have been skipping. Consider explaining an asynchronous method in C#. “It runs in the background” sounds convenient, right up until someone asks which thread is doing the work. Now you have to explain what is actually waiting, what can continue, and why asynchronous does not automatically mean parallel.

The gap was already there. Teaching made it visible. That moment can feel uncomfortable, especially when you are the experienced person in the room. Your title arrived before you did. People expect answers. You may start expecting yourself to have all of them. But seniority should make us better at handling uncertainty. It should make “I don’t know yet” easier to say, followed by “Let’s work it out.”

I want to bring that mindset to the communities I help build, from FINOS to .NET Foundation to my Zenith conversations and conference presentations. Bringing people together creates opportunities to ask questions that would never emerge from reading alone. Someone connects the topic to a different industry. Someone challenges an assumption. Someone asks the basic question that half the room was quietly carrying.

A useful session leaves the presenter with something to investigate, too.

𝗧𝗵𝗲𝗿𝗲 𝗶𝘀 𝗮 𝗿𝗲𝘀𝗽𝗼𝗻𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 𝘁𝗵𝗮𝘁 𝗰𝗼𝗺𝗲𝘀 𝘄𝗶𝘁𝗵 𝗹𝗲𝗮𝗿𝗻𝗶𝗻𝗴 𝗼𝘂𝘁 𝗹𝗼𝘂𝗱.

Being willing to share unfinished understanding means being clear about where it is unfinished.

• “This is what I tested.”
• “This is the conclusion I am drawing.”
• “This part still needs validation.”

Those distinctions matter. A confident explanation can travel much further than the evidence behind it. In engineering, other people may build on what we say. We owe them enough context to judge it. Share the example. Name the limitation. Welcome the correction. When your understanding changes, update the explanation where people can find it.

An old post with a visible correction can teach something valuable about the subject and about how to handle being wrong. AI makes this discipline even more useful. A tool can produce a polished explanation for us, and we can read it, agree with it and mistake that agreement for understanding. Try closing the answer and teaching the idea yourself.

Use a different example. Explain the trade-off. Answer a follow-up question. Identify where the advice would fail. That is where you find out how much of the explanation has become your own knowledge. For leaders, there is a practical implication here: make room for people to share work while questions are still open. A ten-minute walkthrough can do it. So can a code review, a short internal note, a documentation improvement or a demo that includes the failed attempt. These are small opportunities to turn individual discovery into something the team can use.

Then pay attention to your response when someone gets challenged. If admitting a gap costs people credibility, they will learn to hide gaps. If a thoughtful correction earns respect, they have a reason to bring their thinking into the room earlier.

We help set that expectation every time we say, “Good question. I need to check that.” You do not need a conference stage to begin. Pick one thing you learned this week. Explain it to someone who could use it. Leave enough room for them to ask a question you did not prepare for. You may help them move forward. You may discover where you need to go next.

𝗟𝗲𝗮𝗿𝗻 𝗼𝘂𝘁 𝗹𝗼𝘂𝗱. 𝗧𝗲𝗮𝗰𝗵𝗶𝗻𝗴 𝗶𝘀 𝗹𝗲𝗮𝗿𝗻𝗶𝗻𝗴 𝘄𝗶𝘁𝗵 𝘁𝗵𝗲 𝗹𝗶𝗴𝗵𝘁𝘀 𝗼𝗻.

What did you think you understood until you tried to teach it?

SQL Server 2016 reached the end of extended support in July 2026, which means it no longer receives regular security updates unless you pay for Extended Security Updates (ESUs).

Your realistic options are to upgrade to SQL Server 2025, upgrade to SQL Server 2022, or buy ESUs for up to three more years (to July 2029), whether you run SQL Server on-premises or in Microsoft Azure.

For most production systems, I recommend a side-by-side migration to SQL Server 2025 unless an application vendor or a removed feature rules it out.

The right approach ultimately depends on application compatibility, infrastructure constraints, acceptable downtime, licensing costs, and how long the new environment needs to remain supported.

In this article, I’ll cover the key decisions (in-place vs side-by-side, SQL Server 2022 vs SQL Server 2025, on-premises vs Microsoft Azure, and ESUs), plus a pre-upgrade checklist and rollback advice to keep risk low.

What are you trying to achieve with your SQL Server 2016 upgrade?

Before making an upgrade decision, you need to work out what exactly you’re trying to achieve. This might seem obvious but, in many organizations I’ve worked in, it’s actually not.

Some just see the support lifetime and want to get onto a supported version as fast and as disruption-free as possible, while others take advantage of the interruption by consolidating their servers, replacing old systems (or improving their availability) – or even moving their workloads to Azure.

What to find out before choosing a SQL Server 2016 upgrade strategy

Whenever I’m discussing this type of upgrade with clients, there are several things I want to know:

It’s critical to really check out what’s being used in terms of third-party applications, since vendors often certify their software for specific SQL Server versions. I know that Microsoft has been telling them for years to target database compatibility levels instead of database server versions, but the message still isn’t getting through to them.

Even if an application works perfectly on SQL Server 2025, there may be a roadblock if the vendor will only support it on SQL Server 2022. It’s unlikely that the client organization will be happy to move to a setup that breaks their vendor support.

You must also consider the level of operating system (OS) support. It was common to install SQL Server 2016 on Windows Server 2016, for example, but that’s not possible with SQL Server 2025. We usually find that those servers need an infrastructure refresh anyway.

What you find here should determine the strategy you use for upgrading from SQL Server 2016, and there are two core ways of doing this.

In-place upgrade vs side-by-side migration: which should you choose?

There are two core ways to upgrade from SQL Server 2016: install the new version over the existing instance (in-place), or build a new instance and move your databases to it (side-by-side).

In-place upgrade (pros, cons, and risks)

One way of upgrading from SQL Server 2016 is by an in-place upgrade, which installs the newer SQL Server version over the existing instance.

The main advantage of this approach is simplicity – there’s no need to migrate every database, recreate logins, or redirect applications to another server.

However, there are also some downsides to this approach. The fact that you are modifying the existing instance, for example, can make rollback difficult. I generally won’t ever do this unless I know that a full image backup of the server and all associated drives has been made.

Additionally, the upgrade itself requires downtime, and you need to allow for a rollback time window in case that’s necessary. I can’t tell you how often I see clients who have not allowed sufficient time for potential rollback situations.

Can you upgrade SQL Server 2016 directly to SQL Server 2025?

If you’ve applied Service Pack 3 (SP3) for SQL Server 2016 (as you should have by now), then a direct in-place upgrade to SQL Server 2025 is supported, presuming the edition and OS requirements are met. There’s no need to make a transition step through SQL Server 2019 or 2022 first.

Side-by-side migration (pros, cons, and how it works)

Side-by-side migration involves building a new SQL Server instance and migrating databases and associated objects to it. While this can of course be more work, there are many advantages to doing this.

The new environment can be built, configured, and tested independently – and both the hardware and operating systems can be upgraded at the same time. You also might be able to migrate applications one by one rather than all at once.

And lastly, the original setup might remain available for testing.

One important lesson I can offer from the school of hard knocks: use different service accounts, logins, etc. for the upgraded system.

I’ve seen clients who had both the old and new systems available on a single network, and applications talked to a mixture of the systems. What a mess!

How to run a side-by-side migration: backup and restore, log shipping, or availability groups

There are many options for how to do the actual migration. You can use backup and restore, log shipping, and availability-group-based approaches where supported.

I recommend log shipping for large database migrations. How log shipping works is simple: a final tail log is taken on the old system and applied to the new system when you’re ready to migrate. I’ve seen that take only a few seconds.

It’s for these reasons that I prefer carrying out a side-by-side migration for most production systems.

In-place vs side-by-side at a glance

SQL Server 2022 vs SQL Server 2025: which should you upgrade to?

Clients used to be hesitant about upgrading to a new version of SQL Server, instead choosing to wait until at least one service pack had been released, but the approach has been different since the discontinuation of service packs nearly a decade ago.

As I mentioned earlier, I see customers choosing SQL Server 2022 simply because it’s been available for longer and they think that means it’ll be more stable. That’s not quite how I see it, though.

Ever since the team moved to using a common code base (many years ago), the best patched version of SQL Server 2022 is SQL Server 2025.

If you’re using brand new features in SQL Server 2025, that’s a different story – but if you’re using the same features that you were using on SQL Server 2016, SQL Server 2025 is the best patched version of SQL Server you can use.

Given SQL Server 2022 reaches the end of extended support in January 2033, and SQL Server 2025 extends that to January 2036, moving to SQL Server 2025 gives you another three years of supported lifecycle. That’s an important difference if you’re undertaking a substantial migration.

After all, why invest heavily in an upgrade only to face another one sooner than you need to?

In my experience, SQL Server 2025 just runs SQL Server 2016 applications better. It’s the result of various improvements such as intelligent query processing, security, developer capabilities, and integration with modern data platforms.

At my company, we’ve been particularly impressed with the adaptive query plan changes that have happened over the years.

However, SQL Server 2025 is not better for every workload. There are many things you need to consider, like changes to linked-server connectivity and requirements around encryption.

Also, some components have been removed, such as Master Data Services (MDS) and Data Quality Services (DQS).

That hasn’t affected us and our clients yet, but you need to check your own situation. If you rely on MDS and/or DQS, or a software vendor hasn’t certified SQL Server 2025, SQL Server 2022 is probably better for you in the interim.

Verdict: choose SQL Server 2025 unless there’s a clear reason not to

My preference would be SQL Server 2025 for new migrations, unless there is a demonstrated technical or commercial reason to remain on SQL Server 2022.

SQL Server 2022 vs SQL Server 2025 at a glance

Keep SQL Server on-premises or move to Azure?

Upgrading SQL Server versions may also be a good time to consider exactly where you want SQL Server to be run. On-premises or in the cloud?

Keeping SQL Server on-premises can make sense where workloads depend on local applications, low-latency connectivity, particular hardware configurations, or existing infrastructure investments.

On the second point, never underestimate the impact of latency differences! Last year, I did work for a bank who were moving their systems to AWS-based cloud infrastructure. In theory, they had provisioned resources that were about eight times the size of what they had on-premises.

The result? An overnight process that used to take two hours, now took eight (and that’s why they got us involved!) As it turned out, most of the issue was latency – the applications were simply too chatty.

How to migrate your SQL Server to Azure: the three options compared

If Microsoft Azure is your target for a SQL Server migration, you have three options. Below, I’ll explain each one to help you determine which is best for your use case.

Azure SQL Database: most change, best for new applications

Azure SQL Database is my preferred choice for a SQL Server migration, but it’s more complex than just migrating an existing on-premises SQL Server database. You need to be prepared for redevelopment work.

Migrating to Azure SQL Database makes most sense for greenfield applications (software built entirely from scratch).

SQL Server on an Azure VM: closest to what you run today

SQL Server is highly compatible with Azure Virtual Machines (VMs). Chances are, when running an environment on an Azure VM, it’ll be very close to what you’re already running (or have run in the past).

Azure SQL Managed Instance: the middle ground

Azure SQL Managed Instance is, in many ways, the middle ground. You don’t need to manage the platform beneath it, and you can take advantage of automated patching and built-in high availability.

It’s not the same as SQL Server, though. If you’re using features like FILESTREAM or FileTable, you need to consider alternatives.

Azure migration options at a glance

What else to consider before a potential Azure migration

You also need to consider the cost implications of a potential Azure migration, but don’t just focus on the price of the database service. Make sure you compare the complete cost of compute, storage, licensing, backup, availability, and administration.

A potential move to Azure is often a separate architectural decision and, with most of my clients, SQL Server 2016 reaching end of support would rarely trigger the move.

It might be a good idea, though, and preparing for an upgrade is as good a time as any time to consider it.

SQL Server 2016 Extended Security Updates (ESUs): length, cost, and limits

You might run into a situation where you simply need to keep running SQL Server 2016. If you don’t want to be unsupported during this time, Extended Security Updates (ESUs) provide critical security updates for three additional years, ending in July 2029.

However, ESUs aren’t the equivalent of ‘normal’ product support, so don’t expect new functionality or routine bug fixes. You also need to consider the cost. I’m always nervous about mentioning prices, but I’m told by customers that Microsoft have quoted around 75% of the on-premises license cost each year.

Note: I only mention that as a guide. Actual charges depend on many things.

There was a period when moving an unsupported SQL Server workload to an Azure VM automatically unlocked free ESU support, but I’m told that’s no longer the case and SQL Server 2016 VM ESUs must be paid for.

Again, though, talk to Microsoft for further information specific to your use case.

ESUs might be useful if you know an application vendor needs more time before upgrading, and they’ve already committed to development of a ‘replacement’ version.

Otherwise, it’s probably time to find a new application vendor instead.

Database compatibility levels: why they matter when upgrading

Originally introduced to avoid upgrade blockers, database compatibility levels have been useful tools over the years.

Imagine you had a database object called ‘XYZ’, but ‘XYZ’ has suddenly just become a reserved word in the latest version of SQL Server. That could stop you dead in your tracks, but with database compatibility levels you could run the code with the previous level while upgrading your code to avoid the issue.

Nowadays, however, they’re much more than that. Your database doesn’t have to be at the same level as your server, for example.

A database running at compatibility level 130 on SQL Server 2016 can stay on that level after moving to either SQL Server 2022 or 2025 – allowing the engine upgrade and compatibility-level change to be treated as separate activities.

I’d still recommend that you initially keep the existing compatibility level to make sure the apps work as expected. You can then raise the compatibility level as a separate, planned change. Try to avoid running at the lower compatibility level indefinitely.

SQL Server upgrade checklist: 7 things to do before you start

Before scheduling a SQL Server version upgrade, I’d suggest you do the following (and it’s more than just running SQL Server Setup).

Take inventory

Record databases, SQL Server versions and editions, operating systems, service accounts, linked servers, SQL Agent jobs, SSIS packages, encryption keys, and high-availability configurations.

Check application support

Confirm that applications, drivers, and third-party components support the proposed SQL Server version.

Check version compatibility

Identify any discontinued features, deprecated syntax, or configuration changes that could block the migration

Establish performance baselines

Before starting a SQL Server version upgrade, make sure you capture representative CPU, memory, I/O (input/output), query-duration, and wait-statistics. If it makes sense for you, enable and configure Query Store (which I know is not for everyone!)

Validate backups

Take current full backups, ensure the necessary log-backup chain is available, and perform test restores on other servers. Make sure that encryption certificates and keys really are both available and recoverable.

Rehearse the migration

Where possible, rehearse the complete migration using a representative workload, including application connectivity, security, scheduled jobs, and maintenance operations.

Document the cutover process

Define the sequence of activities, responsibilities, expected downtime, validation checks, and the point at which rollback will be required.

SQL Server upgrade rollback: why you need a plan before you start

I often find that rollback is the weakest part of the upgrade plan for many organizations. They tend to forget that SQL Server database upgrades are usually one-way operations.

This is because, once a database has been upgraded to a newer engine version, its files or newer-version backups can’t simply be restored onto SQL Server 2016 – even if the database compatibility level stays the same.

While an in-place upgrade might seem simple, recovery might require you to rebuild the whole environment and restore backups.

Even though you still have the original system with a side-by-side upgrade, you might have a data issue if any work was attempted on the upgraded system. That would potentially be lost.

Summary: how to upgrade from SQL Server 2016

If you’re using SQL Server 2016, you probably don’t need to move away from it – but the support deadline shouldn’t be the only decision point.

Generally, I’d recommend a side-by-side migration to SQL Server 2025 and that will be the strongest long-term option, but only if your application support is available. If not, SQL Server 2022 might still be a valid choice, but I’d suggest only where application compatibility or vendor certification demands it.

If you are upgrading, you should consider whether Azure SQL Managed Instance or SQL Server on Azure VMs make sense.

Finally, if more time is genuinely needed, Extended Security Updates can provide some limited breathing space.

In the end, you don’t just want to end up with a new version of SQL Server. You need to have an environment that’s supported, tested, recoverable, and better positioned for the years ahead.

The post SQL Server 2016 end of support: how to choose your upgrade path appeared first on Simple Talk.