Blog Post

Exchange Team Blog
4 MIN READ

Why “in-place upgrade” from Exchange 2019 to Exchange SE is low risk

The_Exchange_Team's avatar
May 01, 2025

We wanted to write an article related to a very frequent customer question related to Exchange Server 2019 to Exchange Server Subscription Edition (SE) migration.

As we mentioned in Upgrading your organization from current versions to Exchange Server SE – there are two ways to migrate to Exchange SE, when released:

  • Traditional (legacy) migration. The “add a new Exchange server to your organization and migrate mailboxes to it” approach. This is mandatory if you are moving from Exchange 2016 to Exchange SE, but is optional if you are moving from Exchange 2019 to Exchange SE.
  • In-place upgrade. The “Install Exchange SE Release to Manufacturing (RTM) build on top of Exchange 2019 CU14/CU15, upgrading your Exchange 2019 servers into Exchange SE servers” approach. This is new and is the approach that some customers see as “too good to be true” and possibly risky.

Let us explain why we view this second approach as “low risk”.

How RTM of a new Exchange version used to be created

In the past, when a new version of Exchange was released, we would make significant changes to the code base. The following is a simplification, but it gives you a general idea. Usually we would:

  1. About two years before the release of the new version, take a version of the current in-market product as “base code” of the new product
  2. Add and remove a bunch of features
  3. Change installation prerequisites
  4. Set new minimum hardware requirements
  5. Create and require new product keys
  6. Change the “major / minor version of code” in our build system (you can see this change from “15.00” in Exchange 2013, to “15.1” in Exchange 2016 and “15.2” in Exchange 2019 as per this page)
  7. Close to the release date, port over any significant features, security or hotfix updates released for the current in-market product in last 2 years (because Step 1 above was done long ago)
  8. Change the product name and update the EULA (End User License Agreement) – which is a file in the Exchange image

Because many of those changes were significant, this essentially required customers to do the following:

  • Perform a legacy (side-by-side) migration.
  • Do a significant amount of testing in their organizations to ensure that added or removed features do not interfere with their business processes or 3rd party applications.
  • Develop training for end users (because of significant product changes).
  • Wait for CU1, because RTM build was seen as “high risk” as many features were added / removed. (Note: waiting was never a requirement, but we know many customers would wait for at least CU1 before migrating).

How we are creating Exchange SE RTM

As opposed to the long list above, Exchange SE RTM is being built as follows:

  1. Start with Exchange 2019 CU15 (our most recent CU) as “base code”
  2. Add any security or hotfix updates publicly released since CU15
  3. Change the product name and update the EULA (End User License Agreement) – which is a file in the Exchange image

Note that the first two things above happen during release of every single Exchange CU. Exchange CUs are always “cumulative” and contain all of the fixes released since the “last CU” (read more here). Therefore, the only new change in Exchange SE RTM is “3. Change the product name and update the EULA”.

We are not doing any of the following in Exchange SE RTM, compared to Exchange 2019 CU15:

  • Changing the major version of code
  • Adding / removing different features
  • Fixing any bugs that are not already released as updates for CU15
  • Adding / requiring new product keys
  • Changing installation prerequisites or hardware requirements

Because of all of this, installing Exchange SE RTM on your Exchange 2019 CU14/CU15 server is essentially installing Exchange 2019 “CU16”, but we changed the name of this CU to be “Exchange SE RTM”.

Why upgrade then? What is the point of all this?

There are several ways in which we believe this approach takes the time pressure off your organizations:

  • It is a simple “no significant changes since Exchange 2019 CU15” installation, so there is no need for extensive testing and validation.
  • By upgrading to this Exchange 2019 CU16 SE RTM build, you switch from the Fixed lifecycle policy of Exchange 2019 (end of support life on October 14, 2025) to the Exchange SE Modern lifecycle policy and your product is supported after October 14, 2025.
  • Even if you want to upgrade your Exchange 2019 hardware for Exchange SE, you can in-place upgrade to Exchange SE first on old hardware and then, once you are on the new support lifecycle path, you have the time to upgrade your server hardware.
  • Feature work for Exchange SE will start in CU1; as your organization can be on the “low risk” but supported RTM release, you will have longer time to test CU1

Conclusion

We realize that with this approach to Exchange SE RTM, we are doing something different, and we probably did not articulate enough just how different it is. As far as engineering work is concerned, Exchange SE RTM is a re-branded “Exchange 2019 CU16” with no features. We released 15 CUs for Exchange 2019 already and have a high degree of confidence that this can be a very low risk action for our customers.

To recap:

Exchange Server Team

Updated May 02, 2025
Version 4.0

15 Comments

  • Dmitriy0806's avatar
    Dmitriy0806
    Copper Contributor

    Hello Exchange Team,

    Thank you for detailed update

    Just like to ask if we can expect any significate changes in Outlook On The Web, similar of Exchange Online in future Exchange SE releases?

     

    • Nino_Bilic's avatar
      Nino_Bilic
      Icon for Microsoft rankMicrosoft

      As of now, this is not something that we have announced.

  • Mugund1987's avatar
    Mugund1987
    Copper Contributor

    Hello Microsoft Team,

    I acknowledge this article is helpful for customers needing clarity beyond official sources. We are on Exchange 2019 CU14 and plan to install Windows Server 2025 and SE on new hardware. Do we need to migrate mailboxes and namespaces from Exchange 2019 CU14 to Exchange SE? I assume it's not required, as Exchange SE is an extended version of Exchange 2019 CU16. Is this understanding correct?

    • Nino_Bilic's avatar
      Nino_Bilic
      Icon for Microsoft rankMicrosoft

      Upgrade of the OS that Exchange is running on DOES require "side-by-side" installation and migration (install, move mailboxes over, decommission old server). This is because upgrade to a different major version of Windows while Exchange is installed is not supported.

      Note that in this case, you could either upgrade to Exchange SE first (on old hardware / Windows OS) and then do migrations to new hardware/OS once you are there - as that will give you more time to do all this - it all depends on your schedule of events.

  • broland's avatar
    broland
    Iron Contributor

    I would like to acknowledge we appreciate any and all news and information we can get about Exchange Server SE, so much appreciated.

    A question (and no this is not a "gotcha" question): would it be fair to say that there will be no more major/minor version changes (i.e. 15.3) coming and that SE will basically just be Exchange 2019 with subsequent CU's?  It sounds basically like it's going to be Exchange 2019 with continued bug fixes/security fixes and maybe a few high profile things here or there (credit for introducing TLS 1.3 and ECC Certificates in CU's).  

    Admittedly I can't think of many major features Exchange is natively missing (*cough* DKIM/DMARC "cough) but it would be nice to know that something significant like an OWA interface refresh might be in the cards.

    • Nino_Bilic's avatar
      Nino_Bilic
      Icon for Microsoft rankMicrosoft

      Our plan is to continue the build numbers without changing the minor or major version going forward, as doing that would likely require a "classic migration" between builds (as opposed to in-place upgrade). I do not foresee a reason why we'd need to change the major or minor version but if we need to do it for some reason, we would (and communicate appropriately, of course).

      Note that all of this does not mean that we do not plan to release any features and we plan to just release updates for "Exchange 2019" for years and year. No, that is not our intent. We have released features in CUs (and plan to continue to do so with Exchange SE). We announced our overview plans for Exchange SE CU1 release for example, here (note that there have been some changes to timing but we still plan to release those). There are other things that we want to do that we did not announce yet etc.

      What I am saying is - we want to continue to provide updates AND we want to continue to release new features AND we want to not require side-by-side migrations so customers can update their servers easier going forward.

  • OldEngineer's avatar
    OldEngineer
    Copper Contributor

    What will the process be for servers in a DAG? Can we update only the DR site and DBs will still replicate? Or disable one from the production HLB pool, upgrade, block the databases from balancing, and test with a test database? How soon do they all need to be done?

    • Nino_Bilic's avatar
      Nino_Bilic
      Icon for Microsoft rankMicrosoft

      The process will be exactly the same as with any CU upgrade. What you do today to install the CU, you just do the same for this upgrade if you are going from Exchange 2019 CU14/15 > Exchange SE.

  • So what build will Exchange SE have? I guess 15.3 according to the current build cadence? You could even say that the CU15 to ‘CU16’ isn’t even a major build bump worthy for now in a way like previous version changes. And will it forever be the same SE build?

    • LukasSMSFT's avatar
      LukasSMSFT
      Icon for Microsoft rankMicrosoft

      The major and minor versions remain unchanged (15.2). Exchange SE will initiate at a specific build, identified by the four-digit number following the major and minor versions.

      • niehweune's avatar
        niehweune
        Brass Contributor

        Small detail: the article should really talk about "change the minor version of code" upon a new version (prior to SE), not the major version :)

  • Great article! This information is incredibly helpful and anwsers alot of questions many have in their minds around the upgrade to Exchange SE. Thanks Nino!

  • Frank-OTJ-BB's avatar
    Frank-OTJ-BB
    Copper Contributor

    Thank you for further clarifying. So when will we be supposed to enter the new licensing key for Exchange SE, server and CALs? You wrote that no key will be requested during the in-place upgrade procedure.

    • Nino_Bilic's avatar
      Nino_Bilic
      Icon for Microsoft rankMicrosoft

      As of right now, we plan to start requiring Exchange SE server keys in CU1. In other words - SE RTM will accept Exchange 2019 key and activate itself (even for new installations).

      As far as licenses are concerned - you do not really "enter" CALs, or sever licenses anywhere in Exchange. Your licensing state / compliance with licensing is completely separate from entering the server key (which we will require at CU1).

  • JamesBaker's avatar
    JamesBaker
    Copper Contributor

    Or, as we are doing, legacy upgrade to Exchange 2019 CU15 on new hardware and server 2025. Then perform the in-place upgrade to SE. We run three domains (2 x 2019 CU14 and 1 x 2016 CU23). End result, all domains on brand new hardware, latest OS and all the same version). Then chill out for the future.