Shopify shipping upgrade reaches its rollout date: what apps and merchants should verify

First determine whether you need to migrate

Shopify’s July 1, 2026 developer announcement and current upgrade guide say merchant-owned shipping configuration is moving into Markets. deliveryProfile and deliveryProfiles are being phased out for merchant configuration, while app-owned profiles keep the existing API. Search GraphQL queries and mutations for deliveryProfile, deliveryProfiles, deliveryProfileCreate, deliveryProfileUpdate and deliveryProfileRemove, marking each operation as targeting a merchant profile or one created by the app.

Impact matrix: apps only creating and maintaining app-owned profiles without reading merchant profiles need no rewrite for this change; apps reading merchant shipping configuration need a new read path; apps creating or modifying merchant profiles need a new write path; mixed apps handle both separately. Separate Carrier Service registration from merchant shipping configuration too. See the Shopify API 2026-10 migration checklist; these timelines must not be collapsed into one API-version upgrade.

After October 1: blog and help-center scope differ

Shopify’s October 1, 2026 official fulfillment guide says all merchants can opt in. This is an explicit blog statement, not our test of every merchant account’s entry point. It does not establish that all stores have upgraded or every app is compatible.

At the October 2 check, the Shipping options by market help page still says early access for selected stores, rolling out gradually, with non-upgraded stores continuing to use shipping profiles. The August 24 official enterprise introduction describes October 1 as the start of opt-in for new merchants and eligible existing merchants, and July 1, 2027 as the target for all merchants to move. These official pages differ in scope wording; this article retains that discrepancy. Store-specific eligibility, rollout batches, entry points and actual upgrade results still require confirmation in authorized accounts.

The current app-upgrade guide still requires checking new-installation warnings for incompatible apps and warns of breakage when existing merchants manually enable the feature before an app upgrades. Shopify will not automatically migrate merchants using an app until it confirms compatibility. Target dates may change; public dates cannot replace the app team’s checks of actual store mode and compatibility warnings.

Checks before merchants actually enable it

First, in authorized Shopify admin, establish whether the store uses traditional shipping profiles or shipping options under Markets. Record any upgrade or enablement entry point and app compatibility warnings. The help center says new shipping options are managed in Markets, while non-upgraded stores retain shipping profiles. If no entry point appears, check eligibility through the help center and Shopify support rather than treating broad blog wording as a forced-switch procedure.

Second, have the app team confirm whether it reads or modifies merchant profiles and use ShopFeatures.marketDrivenShipping to verify actual mode, then inspect the relevant read/write paths below. Third, compare products, markets, locations, charges and representative checkout addresses within a controlled scope. Stop expanding enablement if compatibility warnings or rate anomalies exist. This article supplies checks only; it has not signed into merchant admin, enabled features or tested checkout.

Read paths: choose feeds or Markets API according to purpose

For a sales-channel app or one that can become a sales channel, Shopify recommends Contextual Product Feeds. They provide shipping-option estimates by product variant and market, covering both merchant market rates and app-owned rates, and require read_product_listings. Confirm coverage of the countries, regions, products and rate data actually needed. Do not force this path if the app lacks eligibility or needs raw configuration.

When reading merchant shipping configuration directly, use ShopFeatures.marketDrivenShipping to detect mode: read Market.delivery in the new mode and deliveryProfiles in the old mode, with read_markets permission required. During transition, compare the same markets, products, locations and rates in both modes. A successful API request alone does not establish correct checkout rates.

Write paths: isolate app rates first, then assess Markets API

Shopify recommends that most apps writing merchant shipping configuration move to managing app-owned delivery profiles. Create them with deliveryProfileCreate and configure actual products and locations; assess coversAllItems only when all products are truly covered. Compare old-path and new-profile rates in parallel before stopping writes to merchant profiles. App-owned profiles retain the original API and permissions; not every deliveryProfile operation is being removed.

If app-owned profiles cannot express the required configuration, use Markets API: when ShopFeatures.marketDrivenShipping is true, use marketCreate or marketUpdate; otherwise continue writing the old merchant profile. This path requires read_markets and write_markets. Review permissions and market/rate ownership first, then validate both store modes separately to avoid overwriting other markets with one merchant’s settings.

Development-store preflight, compatibility declaration and acceptance

This requires an available development store and test app version. When creating a new development store, select the Market-driven shipping feature preview; official guidance says this preview cannot be added to an existing store. Prepare a separate controlled store for the old mode, and design fixtures for the app’s actual read paths, write paths and checkout addresses. This is a test plan, not account testing performed for this article.

In both old and new stores, record ShopFeatures.marketDrivenShipping, the relevant Market or profile, permissions, retrieved rates and checkout results for representative products and addresses. Check for duplicated or missing app-owned and merchant market rates. After upgrading and validating, submit compatibility self-attestation according to Shopify guidance so Shopify can mark compatibility and clear merchant warnings. Submitting the form does not replace real read/write and checkout regression tests.

Stop expansion on failure and understand available rollback

Stop expanding enablement if the mode branch disagrees with the actual store, permissions are insufficient, market rates disappear or duplicate, or checkout results are wrong. Preserve store mode, request ID, market, product, location and response evidence. Do not hide configuration or permission errors by changing egress or retrying the same old request.

Merchants still in the old mode may temporarily retain validated old read/write paths. Merchants who manually enabled the new mode must not assume they can revert store state themselves; stop risky writes and follow Shopify-supported handling. This article has not verified any merchant’s rollback permission, migration result or self-attestation status. IP changes cannot fix API mode, permissions or shipping configuration.