SharePoint Online ACS Retirement - What's the correct way to migrate Azure Data Factory (ADF) SPO List Linked Services

Question

SharePoint Online ACS Retirement - What's the correct way to migrate Azure Data Factory (ADF) SPO List Linked Services

ZuheirZ 41

As per the title, I couldn't find any way I can use ADF Linked Services to ingest SharePoint Online List through copy data etc. I found a guide towards File / Library. But not Normal list without the usage of ACS.

I've done everything that is needed in getting the access through MS Graph for the service Principal, but ADF Linked Services for SPO List doesn't seems to be working.

Please help!

Naveena Patlolla 8,600 Reputation points Microsoft External Staff Moderator

2026-03-14T08:49:19.5633333+00:00
Hi ZuheirZ
It looks like you’ve hit the SharePoint Online ACS retirement roadblock—ADF no longer supports the old ACS-based connector for SPO Lists. Instead, you need to go the Microsoft Graph route. Here are two paths you can take:

Use the built-in “SharePoint Online List (Preview)” connector in Copy Activity • In Azure Data Factory, add a new Linked Service and choose “Office 365 SharePoint List.” • For authentication pick “Service Principal,” then supply your tenant, client-ID and client-secret. • Under Site URL enter the full site address (e.g. https://contoso.sharepoint.com/sites/YourSite) and then type the List name. • ADF will internally use Microsoft Graph to enumerate and pull list items.

Use ADF’s HTTP (REST) connector + Graph API Step A: Register an Azure AD app & grant Graph scopes • Go to Azure AD → App registrations → New registration. • Expose an API or add API permissions: Sites.Read.All, Lists.Read.All (as application permissions). • Grant admin consent, then grab your Client ID, Tenant ID and Client Secret. Step B: Create an HTTP Linked Service in ADF • Auth type: OAuth2 • Authority: https://login.microsoftonline.com/<TenantID>/oauth2/v2.0/token • Resource/Scope: https://graph.microsoft.com/.default • Client ID/Secret: from your App registration Step C: Create an HTTP Dataset and Copy Activity • Base URL: https://graph.microsoft.com/v1.0 • Relative URL example:
/sites/<site-id>/lists/<list-id>/items?expand=fields
• In Copy Activity, map the JSON payload (items[*].fields) to your sink.

Both routes are Graph-based and will work post-ACS retirement. Which you choose comes down to whether you want a turnkey connector (preview) or more control via raw REST calls.

Hope this helps get your SPO Lists flowing into ADF again!

Reference docs

• Copy data from a SharePoint Online list by using the SharePoint Online list connector (preview):

https://docs.microsoft.com/azure/data-factory/connector-sharepoint-online-list

• HTTP connector in Azure Data Factory:

https://docs.microsoft.com/azure/data-factory/connector-rest

Follow-up questions (if you’re still stuck):

Are you seeing any specific error messages when you test your Linked Service or run the pipeline?

Which approach did you try (the preview connector or raw HTTP)?

Have you validated your Graph permissions by calling the API in Postman or Graph Explorer?

Can you share the site-ID/list-ID or List name and how you configured the relative URL?
ZuheirZ 41 Reputation points

2026-03-15T01:55:03.2933333+00:00

Thanks for the feedback @Naveena Patlolla !

I do look in utilizing SharePoint Online List with Certificate authentication, however it doesn't seems to work as it return the following error:

Error code: 23201

Details: Failed to get metadata of odata service, please check if service url and credential is correct and your application has permission to the resource. Expected status code: 200, actual status code: Unauthorized, response is : {}.

Now I'm pretty sure I check and all the connection seems to work fine via API directly. But not the ADF Linked Services, checking further on the errors lead me to the following:

https://learn.microsoft.com/en-us/azure/data-factory/connector-troubleshoot-sharepoint-online-list#connection-failed-after-granting-permission-in-sharepoint-online-list

Looks like its going back to ACS , if option 1 failed, then I guess I had to rely on REST and revamp our automation that relying on ADF Linked Services. **Reason why I'm looking to retain ADF Pipeline is to minimize the changes that we need to perform that's part of the bigger automation.
Smaran Thoomu 34,155 Reputation points Microsoft External Staff Moderator

2026-03-17T05:01:28.7633333+00:00
@ZuheirZ You are correct in your observation. After the SharePoint ACS retirement, the old authentication method used by the classic SharePoint List connector is no longer supported. Because of this, some scenarios — especially certificate-based authentication with the current ADF SharePoint Online List (Preview) connector — may still show ACS-related behavior or fail with metadata/unauthorized errors even when Graph permissions are correctly configured.

At the moment, there is no supported way to fully migrate existing ACS-based SharePoint List linked services in ADF without redesign. The preview connector does use Microsoft Graph internally, but it is still evolving and may not work reliably in all authentication scenarios.

So in practice, the recommended and stable approach today is:

Use ADF REST / HTTP connector with Microsoft Graph API for SharePoint Lists

Or move the ingestion logic to Data Flow / Azure Function / Logic App / Fabric pipeline if you want more control

If your goal is to minimize automation changes, the REST + Graph approach is usually the closest replacement because:

It avoids ACS completely

It works with Service Principal + certificate

It gives predictable long-term support

If you want, you can share:

Whether your list is large or incremental

Current pipeline design (Copy / Dataflow)

Authentication type you must keep (cert vs secret)

Then we can suggest the least-impact migration pattern.

Thanks.
ZuheirZ 41 Reputation points

2026-03-18T02:55:39.74+00:00

Hi @Smaran Thoomu

Thanks for confirmation, even though it's the last thing I hope I need to do.

When you mentioned that ADF SharePoint Online List (Preview) connector does use Microsoft Graph internally, I do try it out using Secret authentication instead and its working fine even though the access to the site was given via graph method.

Do you foresee that at least for the few weeks after ACS Retirement, secret authentication may work while we worked on revamping the whole automation.

Just a brief context --> what we are doing is that we have a master list of SharePoint list that the ADF will then ingest and transfer the data from those specific list to our SQL Datawarehouse. This list are used for data mapping, correction and even some of them are use as a primary data source for some solutions. We were happy with how it works right now, till we found out this ACS retirement where there is no direct replacement for it.
Smaran Thoomu 34,155 Reputation points Microsoft External Staff Moderator

2026-03-18T05:48:56.1766667+00:00
Hi @ZuheirZ
Thanks for the update and for sharing your testing results.

Yes, your understanding is correct. After the SharePoint ACS retirement, the classic authentication flow used by older SharePoint List linked services is no longer supported. The SharePoint Online List (Preview) connector now relies on Microsoft Graph, but it is still evolving and some authentication scenarios - especially certificate-based auth - may not behave consistently.

Since you confirmed that client secret authentication is currently working, you can continue to use it as a temporary approach while you plan the migration. However, this should be treated only as a short-term workaround, as behavior may change and Microsoft is gradually moving all scenarios to fully supported Graph-based patterns.

For long-term stability, the recommended approach is still:

Use ADF REST / HTTP connector with Microsoft Graph API for SharePoint Lists

Or redesign ingestion using ADF Dataflow / Azure Function / Fabric pipeline, depending on automation complexity

This ensures:

No dependency on retired ACS components

Better long-term supportability

More predictable authentication behavior

If your current design depends on dynamically ingesting multiple lists from a master list, the Graph REST approach is usually the closest architectural replacement with minimal functional change.

If helpful, you can share:

Approximate number and size of lists

Whether ingestion is full or incremental

Current pipeline pattern (Copy vs Dataflow)

Based on that, we can suggest the lowest-impact migration strategy.

Thanks.

1 answer

Your answer

ZuheirZ 41 Reputation points

2026-03-15T01:55:03.2933333+00:00

Thanks for the feedback @Naveena Patlolla !

I do look in utilizing SharePoint Online List with Certificate authentication, however it doesn't seems to work as it return the following error:

Error code: 23201

Details: Failed to get metadata of odata service, please check if service url and credential is correct and your application has permission to the resource. Expected status code: 200, actual status code: Unauthorized, response is : {}.

Now I'm pretty sure I check and all the connection seems to work fine via API directly. But not the ADF Linked Services, checking further on the errors lead me to the following:

https://learn.microsoft.com/en-us/azure/data-factory/connector-troubleshoot-sharepoint-online-list#connection-failed-after-granting-permission-in-sharepoint-online-list

Looks like its going back to ACS , if option 1 failed, then I guess I had to rely on REST and revamp our automation that relying on ADF Linked Services. **Reason why I'm looking to retain ADF Pipeline is to minimize the changes that we need to perform that's part of the bigger automation.
Smaran Thoomu 34,155 Reputation points Microsoft External Staff Moderator

2026-03-17T05:01:28.7633333+00:00

@ZuheirZ You are correct in your observation. After the SharePoint ACS retirement, the old authentication method used by the classic SharePoint List connector is no longer supported. Because of this, some scenarios — especially certificate-based authentication with the current ADF SharePoint Online List (Preview) connector — may still show ACS-related behavior or fail with metadata/unauthorized errors even when Graph permissions are correctly configured.

At the moment, there is no supported way to fully migrate existing ACS-based SharePoint List linked services in ADF without redesign. The preview connector does use Microsoft Graph internally, but it is still evolving and may not work reliably in all authentication scenarios.

So in practice, the recommended and stable approach today is:

Use ADF REST / HTTP connector with Microsoft Graph API for SharePoint Lists

Or move the ingestion logic to Data Flow / Azure Function / Logic App / Fabric pipeline if you want more control

If your goal is to minimize automation changes, the REST + Graph approach is usually the closest replacement because:

It avoids ACS completely

It works with Service Principal + certificate

It gives predictable long-term support

If you want, you can share:

Whether your list is large or incremental

Current pipeline design (Copy / Dataflow)

Authentication type you must keep (cert vs secret)

Then we can suggest the least-impact migration pattern.

Thanks.
ZuheirZ 41 Reputation points

2026-03-18T02:55:39.74+00:00

Hi @Smaran Thoomu

Thanks for confirmation, even though it's the last thing I hope I need to do.

When you mentioned that ADF SharePoint Online List (Preview) connector does use Microsoft Graph internally, I do try it out using Secret authentication instead and its working fine even though the access to the site was given via graph method.

Do you foresee that at least for the few weeks after ACS Retirement, secret authentication may work while we worked on revamping the whole automation.

Just a brief context --> what we are doing is that we have a master list of SharePoint list that the ADF will then ingest and transfer the data from those specific list to our SQL Datawarehouse. This list are used for data mapping, correction and even some of them are use as a primary data source for some solutions. We were happy with how it works right now, till we found out this ACS retirement where there is no direct replacement for it.
Smaran Thoomu 34,155 Reputation points Microsoft External Staff Moderator

2026-03-18T05:48:56.1766667+00:00

Hi @ZuheirZ
Thanks for the update and for sharing your testing results.

Yes, your understanding is correct. After the SharePoint ACS retirement, the classic authentication flow used by older SharePoint List linked services is no longer supported. The SharePoint Online List (Preview) connector now relies on Microsoft Graph, but it is still evolving and some authentication scenarios - especially certificate-based auth - may not behave consistently.

Since you confirmed that client secret authentication is currently working, you can continue to use it as a temporary approach while you plan the migration. However, this should be treated only as a short-term workaround, as behavior may change and Microsoft is gradually moving all scenarios to fully supported Graph-based patterns.

For long-term stability, the recommended approach is still:

Use ADF REST / HTTP connector with Microsoft Graph API for SharePoint Lists

Or redesign ingestion using ADF Dataflow / Azure Function / Fabric pipeline, depending on automation complexity

This ensures:

No dependency on retired ACS components

Better long-term supportability

More predictable authentication behavior

If your current design depends on dynamically ingesting multiple lists from a master list, the Graph REST approach is usually the closest architectural replacement with minimal functional change.

If helpful, you can share:

Approximate number and size of lists

Whether ingestion is full or incremental

Current pipeline pattern (Copy vs Dataflow)

Based on that, we can suggest the lowest-impact migration strategy.

Thanks.

Answer 1

Azure Data Factory’s SharePoint Online List connector still relies on a service principal model that is based on Azure ACS for app-only access. Because Azure ACS is being retired, the recommended path is not to “fix” the existing ACS-based linked services, but to move away from ACS-based authentication entirely.

Key points from the current guidance:

Azure ACS retirement impact
- Azure ACS for SharePoint Online auth will stop working for new tenants as of November 1, 2024 and for existing tenants on April 2, 2026.
- The SharePoint Online List connector documentation explicitly recommends switching from service principal key authentication (ACS-based) to service principal certificate authentication, but both are still ACS-style app principals at the SharePoint level.
- Long term, the supported and preferred model for app-only access to SharePoint Online is via a Microsoft Entra ID (Azure AD) application, not ACS.
Current ADF SharePoint Online List connector model
- The connector uses a service principal that is granted permissions directly in SharePoint via the appinv.aspx page.
- The documented setup steps are:
  1. Register an application with Microsoft Entra ID and note Application ID, key/certificate, and Tenant ID.
  2. Grant SharePoint Online site permissions to that app using https://<your-site-url>/_layouts/15/appinv.aspx with an AppPermissionRequests XML such as:
```
        <AppPermissionRequests AllowAppOnlyPolicy="true">
            <AppPermissionRequest Scope="http://sharepoint/content/sitecollection/web" Right="Read"/>
        </AppPermissionRequests>
```
  3. In ADF/Synapse, create a SharePoint Online List linked service and configure it with that app’s details.
- This path is still ACS-style app-only under the covers, even when the app is registered in Entra ID.
What this means for migration
- There is no alternative ADF-linked-service authentication mode in the provided documentation that uses pure Entra ID app-only / Microsoft Graph for SharePoint Online List ingestion.
- The official guidance for ACS in SharePoint Online is:
  - Prefer Entra ID app-only over ACS for new solutions.
  - Plan to migrate off ACS-based models before April 2, 2026.
- For SharePoint in general (outside ADF), the recommended replacement is:
  - Register an Entra ID application and use Entra ID app-only with either Microsoft Graph or SharePoint REST, optionally using Resource Specific Consent (RSC) to scope permissions to specific site collections.
Practical options based on current documentation
- For existing ADF SharePoint Online List linked services:
  - They can continue to work while ACS is still supported, but must be considered temporary because ACS will stop working.
  - If using service principal key, switch to service principal certificate authentication as recommended in the connector docs to align with current best practice for that connector.
- For a long-term, ACS-free architecture:
  - Move ingestion logic to a component that can use Entra ID app-only and Microsoft Graph/SharePoint REST (for example, an Azure Function, Logic App, or custom code) and then land data into a storage or database that ADF can read from.
  - Use ADF to orchestrate around that component rather than connecting directly to SharePoint Lists via the ACS-based connector.
Tenant-level ACS shutdown
- Tenant admins can proactively disable ACS app-only access using:
```
     Connect-SPOService -Url https://<tenant>-admin.sharepoint.com
     Set-SPOTenant -DisableCustomAppAuthentication $true
```
- Once this is done (or after the global retirement date), ACS-based ADF SharePoint Online List linked services will no longer be able to authenticate.

In summary, the current ADF SharePoint Online List connector does not expose a Microsoft Graph / Entra ID–only mode in the provided documentation. The supported migration path is to:

Treat the existing ACS-based linked services as temporary.
For now, use the documented service principal setup (preferably certificate-based) if ACS is still enabled in the tenant.
Design a replacement ingestion pattern that uses Entra ID app-only and Graph/SharePoint APIs outside of the ADF SharePoint List connector, then feed ADF from that landing zone.

References:

Share via

SharePoint Online ACS Retirement - What's the correct way to migrate Azure Data Factory (ADF) SPO List Linked Services

1 answer

Your answer