Wanted to upgrade exchange server from 2010sp2 to 2019

Question

Wanted to upgrade exchange server from 2010sp2 to 2019

jadav Suresh 0

I have code implemented for 2010sp2 used to connect with customer inbox using hosted url and basic credentials like user name and password.

Now as support for this version ended, wanted to migrate or upgrade to new latest version 2019 on-premise version or cloud hosted version. so wanted to know the process that changes needed at code level and what customer has to do at their end?

0 comments

2 answers

Your answer

Answer 1

Hi jadav Suresh,

Thank you for posting your question in the Microsoft Q&A forum.

Based on your description (“hosted URL” + “basic credentials” to connect to a customer inbox), could you please confirm whether the hosted URL you’re using is an EWS endpoint (for example, a URL ending with /EWS/Exchange.asmx)? This is important because the required code and configuration changes depend heavily on the protocol and authentication method you’re using.

Given that Exchange Server 2010 is out of support, you mentioned you are considering either moving to a newer on‑premises version or moving to Exchange Online (cloud hosted). From a “code change” perspective, there are two common scenarios:

If you choose to migrate to Exchange Server 2019 (on‑premises), please note that Exchange Server 2019 has reached end of support on October 14, 2025, so the longer-term on‑premises direction is now Exchange Server Subscription Edition (Exchange SE) rather than starting new on 2019. In addition, there is no direct migration path from Exchange 2010 to Exchange 2019. The commonly referenced guidance is a “double hop” approach (2010 > 2016 > 2019). If you are currently on Exchange 2010 SP2, there is also a prerequisite in this readiness checks before you can introduce Exchange 2016 into the organization: all Exchange 2010 servers must be upgraded to Exchange 2010 SP3 + RU11 (or later) for coexistence with Exchange 2016.
For your application, if it is truly using EWS with Basic authentication against on‑premises Exchange, then in many environments EWS and Basic authentication can still exist on-premises, so you may not need immediate code changes purely for credentials (subject to your customer’s security policy). Your main work in this scenario is likely to be endpoint/namespace updates, certificate/TLS considerations, and validating authentication settings as you move to the new servers. For deployment and upgrade considerations, you can check these references:
If you choose the more future-facing option and migrate to Exchange Online (cloud hosted), then Basic authentication is now disabled in all tenants and cannot be re-enabled. This impacts EWS, Autodiscover, POP/IMAP, and other protocols that previously allowed Basic auth. In this case, you should expect code changes at the authentication layer at minimum. Microsoft also recommends that applications accessing Exchange Online via legacy EWS move toward Microsoft Graph (modern OAuth-based access, more granular permissions). For the tenant/mailbox migration planning itself (separate from the app code), these Exchange Online admin references can help you choose the best migration approach and execute it:

I hope these references help you. If you have any further questions, please feel free to share.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

jadav Suresh 0 Reputation points

2026-01-06T17:51:54.4233333+00:00

Below this basic code we used for calendar operation

try (ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2010_SP2)) { ExchangeCredentials credentials = new WebCredentials(username, password); service.setCredentials(credentials); service.setUrl(new URI(host url)); if (StringUtils.isNotEmpty(******@abc.com)) { service.setImpersonatedUserId(new ImpersonatedUserId(ConnectingIdType.SmtpAddress, impersonate_username)); } Calendar cal = Calendar.getInstance(); cal.add(Calendar.DAY_OF_MONTH, -10); CalendarFolder cf = CalendarFolder.bind(service, WellKnownFolderName.Calendar); cf.findAppointments(new CalendarView(cal.getTime(), new Date())); }

How this will effect once you migrated to different version like 2019, 2019 with hybrid option and full cloud that is microsoft 365 exchange online?
Kudos-Ng 15,050 Reputation points Microsoft External Staff Moderator

2026-01-07T15:02:24.7233333+00:00

Hi jadav Suresh,

Thank you for the additional details.

Given your current implementation uses EWS against a hosted endpoint with Basic (username/password) credentials, the calendar logic can remain as-is while the credential model changes according to the target environment. In a pure Exchange Server 2019 (on‑premises) deployment, EWS is still available and your organization can retain Basic on the EWS virtual directory if policy permits.

In a hybrid deployment where some mailboxes remain on‑premises and others move to Exchange Online, you should resolve the endpoint per mailbox via Autodiscover and use a dual approach: continue EWS Basic if still allowed for on‑premises mailboxes, and use EWS with OAuth 2.0 for Exchange Online mailboxes because Basic is disabled there; impersonation continues to work, but cloud requests must be authorized with app or delegated permissions and sent to https://outlook.office365.com/EWS/Exchange.asmx. In a full Exchange Online scenario, Basic is not available and you must switch to OAuth 2.0 for EWS immediately; your existing bind/findAppointments logic remains, but credentials become a bearer token obtained from Microsoft Entra ID, and the long‑term recommendation is to migrate the integration to Microsoft Graph while EWS in Exchange Online approaches retirement.
Kudos-Ng 15,050 Reputation points Microsoft External Staff Moderator

2026-01-08T09:43:14.94+00:00

Hi jadav Suresh,

Just checking in to see if you had a chance to review the previous response.

Your feedback would be very helpful in ensuring everything is on track.

Answer 2

AI answer

To upgrade from Exchange Server 2010 SP2 to Exchange Server 2019, you will need to follow a structured migration process as direct upgrades from 2010 to 2019 are not supported. Here are the steps you should consider:

Plan the Upgrade Path: You will need to first upgrade to Exchange Server 2013 or 2016 before moving to Exchange Server 2019. This means you will have to set up a new Exchange Server 2013 or 2016 instance, migrate mailboxes and data, and then proceed to upgrade to Exchange 2019.
Prepare the Environment: Ensure that your current environment meets the prerequisites for Exchange 2019. This includes hardware requirements, software prerequisites, and ensuring that Active Directory is prepared for the new version.
Migrate Mailboxes: After setting up Exchange 2013 or 2016, you can begin migrating mailboxes from Exchange 2010 to the new server. Use the Exchange Management Shell or the Exchange Admin Center to facilitate this process.
Upgrade to Exchange 2019: Once all mailboxes are migrated to Exchange 2016 or 2013, you can then install Exchange Server 2019 on a new server or perform an in-place upgrade if you are using Exchange 2016.
Update Code: At the code level, you will need to ensure that your application is compatible with the APIs and protocols supported by Exchange 2019. This may involve updating any references to deprecated APIs and ensuring that your authentication method (basic credentials) is still supported. Exchange 2019 supports modern authentication methods, so consider updating your code to use OAuth if applicable.
Customer Actions: Customers will need to ensure that their email clients and any integrations are compatible with Exchange 2019. They may also need to update their configurations to point to the new server URLs and ensure that any necessary firewall or security settings are adjusted to allow access to the new Exchange server.

It's recommended to consult the official Microsoft documentation for detailed steps and best practices for each phase of the upgrade process.

References:

AI-generated content may be incorrect. Read our transparency notes for more information.

Share via

Wanted to upgrade exchange server from 2010sp2 to 2019

2 answers

Your answer