How do you migrate from Shopify Plus to Magento Open Source without losing catalog or orders?
The move is a data and integration rebuild run as a parallel operation, not a file upload. If your catalog is large and your renewal, hosting cost or data residency terms are pushing you to act, plan for an in-house platform team to own the project with an implementation partner covering the heavy lifting. Magento Open Source is self-hosted and licensed under the Open Software License 3.0 (OSL-3.0), with AFL 3.0 also included in the distribution, according to the magento/magento2 GitHub repository. Adobe Commerce is a separate, paid edition from Adobe with its own features and support terms, so confirm which one your budget and requirements actually point to before scoping work.
Start with an inventory of what Shopify holds for you: products, variants, metafields, customers, orders, redirects, and every app whose data or checkout behavior you depend on. Shopify's product CSV does not include images, so keep the original store live until the new store has imported images from their public URLs. Customer exports are capped at 15 MB per file, so split large exports before loading. Your team should confirm which order history, discounts and metafields need the Admin API rather than CSV, since the CSV route will not carry everything. Decide early which records you migrate in full and which you archive read-only.
Plan the cutover around a parallel run. Keep Shopify live, load the Magento catalog and test order flow against a staging environment, then reconcile product counts, prices, tax settings and customer accounts before switching DNS. Set up 301 redirects from every indexed Shopify URL to its Magento equivalent and validate them with a crawl. Payment gateway setup, checkout configuration and PCI scope must be tested end to end on the live payment provider before go-live. Ask your partner for a written test plan and a rollback path, and confirm the Magento version and support window with the Adobe Commerce lifecycle policy before you pick a release line.
Which Shopify Plus capabilities map cleanly to Magento Open Source and which need rework
This table sorts the Shopify Plus capabilities a catalog-heavy store relies on into clean moves, items that need rework, and gaps you must close yourself. Read each row as a planning starting point, because Magento equivalents must be confirmed against your installed version and the extensions you choose. The main takeaway is that data moves are usually the easy part, while apps, Shopify Functions, checkout logic and hosted uptime become work you own.
| Capability | Magento Open Source position | Status |
|---|---|---|
| Product catalog and variants | Products, configurable options and attributes can be modeled, but Shopify CSV columns must be mapped to Magento import templates. | Needs rework |
| Customer accounts | Customer records can be imported from a CSV export, but passwords are not portable, so customers usually reset them or migrate on next login. | Needs rework |
| Order history | Past orders can be stored as imported records or an archive, but Magento does not reproduce Shopify order status and fulfillment history automatically. | Gap |
| Product images | Shopify CSV exports omit images, so you re-import them from public URLs and keep the original store live until that import completes. | Needs rework |
| Apps | Shopify apps have no direct equivalent, so each function must be matched to a Magento extension or custom module and confirmed for compatibility. | Needs rework |
| Shopify Functions and automatic discounts | Discount rules and checkout logic written as Shopify Functions must be rebuilt as Magento cart price rules or custom code, and automatic discounts may not export. | Gap |
| Checkout and payments | Magento provides checkout, but payment gateways, tax and fraud tools must be installed, configured and tested, and PCI scope moves to your environment. | Needs rework |
| URL redirects | Old Shopify URLs can be mapped to Magento URL rewrites or a redirect file, which must be tested against every indexed product and collection path. | Needs rework |
| B2B features | Magento Open Source has basic store functionality, so company accounts, quotes and negotiated pricing usually need extensions or custom work, and Adobe Commerce is the paid edition that includes more features. | Gap |
| Hosted uptime | Shopify states 99.99% uptime on average on its Plus page, while on Magento you run the hosting, caching, search and patching and own the uptime outcome. | Gap |
What Shopify exports carry over and what you must rebuild
Shopify's admin exports move catalog, customer and order records, but they leave out images, automatic discounts and most app logic. The cards below separate what arrives as data from what you must recreate on Magento Open Source, and what to verify before you cut over.
Product CSV from the admin
The admin product export gives you titles, descriptions, variants, prices and SKUs in one file that Magento's import tooling can read after mapping. Product images are not in that CSV. Shopify advises keeping the original store live until the new store has imported images from their public URLs, so plan the image pass as a separate workstream and confirm every URL still resolves before you switch DNS.
Customer CSV and the 15 MB limit
The customer export includes tags and supported metafields, but Shopify caps the file at 15 MB. A large customer base will split across several files, so plan the split by a stable key and check that each file keeps the same column headers before import. Confirm how Magento handles password hashes and account resets, because exported records do not carry usable logins.
Order history needs the Admin API
Order CSVs do not give you a complete record of line items, fulfillments, refunds and metafields for long histories. For full order history and custom order data, you will need a scripted pull from the Shopify Admin API. Decide early which orders must move (open orders, returns in progress, years of history for finance) and who owns the mapping to Magento order and customer entities.
Shopify apps become Magento extensions
Each Shopify app your store depends on has to be replaced by a Magento extension, a custom module, or a retained third-party service. Inventory every app, its data writes and its checkout or theme hooks before you pick a path. Reviews, subscriptions, B2B pricing and shipping rate apps are common sources of rebuild effort, and each needs an owner, a test plan and a support decision.
Catalog APIs are a pattern, not a Shopify path
BigCommerce's Catalog API manages products, images, variants and metafields programmatically, which shows the kind of endpoint a clean extraction needs. Shopify does not offer that same catalog API, so do not plan around it. Your Shopify equivalent is the Admin API and bulk exports, and that is where your extraction script and its test data should be built.
What happens at each step of a Shopify Plus to Magento migration
The sequence moves a catalog-heavy store from hosted Shopify Plus to self-hosted Magento Open Source in stages, so each stage produces evidence that the next one depends on. The Shopify store stays live until the data and traffic are proven on the new platform.
Inventory catalog, customers, orders and integrations
The team lists every product attribute, variant, collection, metafield, customer tag, order history need, installed app and external integration that the store depends on. DeployOpen and the merchant's commerce owner review the list together and mark which items Magento must replicate, which can be dropped and which need a custom build. The output is a scoped field mapping sheet and an app-to-extension decision log, signed off before any data is moved.
Export data and confirm what the CSVs omit
Products, customers and orders are exported from the Shopify admin, and the team checks each file against the limits Shopify documents, including the 15 MB cap on customer exports. Product images are not in the product CSV, so the export is paired with a list of image public URLs. Where metafields or full order history are needed, the Admin API is used instead. The output is a versioned export set with row counts recorded for each file.
Build the Magento staging stack on supported versions
A staging Magento Open Source instance is built on a combination Adobe lists as supported for the chosen release, such as the PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, Composer and nginx versions in the system requirements. Varnish is configured as the full-page cache for this self-managed install. Custom attributes, tax rules and the chosen payment and shipping methods are configured here. The output is a documented staging environment and a build record that names every version in use.
Run a pilot import and reconcile the results
A subset of products, customers and a sample of historical orders is imported into staging, including image downloads from public URLs and variant mapping. Counts, prices, stock levels, tax settings and customer records are compared row by row against the Shopify exports. Import errors are fixed in the mapping sheet and the pilot is repeated until the reconciled import report shows no unexplained differences. The output is a signed-off import report and a list of accepted exceptions.
Run a parallel period with Shopify live
The Shopify store stays open for customers while the full import, extension configuration, theme and checkout are tested on Magento. Staff place test orders through the payment sandbox, check tax and shipping calculations, confirm Content Security Policy behavior on storefront and payment pages, and run load tests against the Varnish and search configuration. Any data changes made on Shopify during this period are re-exported and delta-loaded. The output is a test log with pass or fail results and a list of open defects that block cutover.
Build and sign off the redirect map
Every indexed Shopify product, collection, page and blog URL is matched to its Magento equivalent, and the team records the redirect rule type for each. Redirects are tested against the staging domain so that old URLs resolve to the correct new pages without chains. The merchant's SEO owner approves the map before the cutover date is set. The output is a signed-off redirect map and a test report showing that sampled legacy URLs return the expected responses.
Cut over DNS, redirects and the payment switch
During a planned window, the final delta export is loaded, DNS records are changed to point the storefront at Magento, redirects go live, and the payment gateway is switched from the Shopify setup to the Magento configuration. Monitoring is checked for errors, failed payments, cache behavior and checkout completion, with a rollback plan ready. The output is a cutover runbook with timestamps, a confirmed test order and a record of the DNS and payment changes made.
Decommission Shopify after the retention window
After the agreed retention period, the Shopify store is closed or downgraded, and a final archive of exports, order records and the redirect map is kept inside the merchant's own storage. Access for former apps and staff is removed, and the team confirms that no payment, email or integration still points at Shopify. The output is a decommission checklist with each item closed, a stored archive and an updated inventory of systems in the merchant's own infrastructure.
What the self-hosted Magento stack requires you to run
Running Magento Open Source means owning every runtime component that Shopify Plus hides from you today. The core set is PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, Composer and nginx. For the 2.4.9 line, Adobe's system requirements list PHP 8.5, MySQL 8.4 or MariaDB 12.3 (recommended) or 11.8, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3, Composer 2.10 and nginx 1.30 on Linux x86-64. For 2.4.8-p5, the list is PHP 8.4 or 8.3, MySQL 8.4 or MariaDB 11.4 or 11.8, OpenSearch 3, Redis or Valkey 8.1, RabbitMQ 4.3, Composer 2.10, nginx 1.30 and Varnish 8. Adobe supports only the listed combinations, so pick one line and one matrix before any build starts. Confirm each version against the Adobe Commerce system requirements page, because a mismatch in any single component can block the upgrade path you planned.
Caching and page delivery are a self-managed decision. Adobe documents Varnish as the full-page cache accelerator for self-managed installations, which means your team configures, tunes and patches it. Cloud-hosted Adobe Commerce uses Fastly instead, so a store that moves between self-managed and cloud hosting later will change its cache layer. Plan the edge layer as part of the hosting design, including the CDN, TLS termination and how purge events from catalog imports reach the cache. Ask your hosting team to load test a full catalog import with Varnish active before go-live.
Content Security Policy is another control you configure rather than inherit. Adobe's developer documentation states that Magento Open Source supports CSP headers from 2.3.5, and from 2.4.7 CSP runs in restrict mode by default on storefront and admin payment pages. Any third-party script, payment iframe or analytics tag you migrate from Shopify must be listed in your policy, or it will fail silently in the browser. Test checkout and the admin payment screens in a staging environment that matches production headers, and record the policy you approved so that your security reviewers can compare it with the configuration later.
What drives the cost and duration of the move
This table lists the components that set the cost and timeline of moving a catalog-heavy Shopify Plus store to self-hosted Magento Open Source, who is paid for each, and whether it is one-time or recurring. Read the sizing drivers first, then ask each vendor or partner to price the rows that apply to your store.
| Cost driver | Why it changes cost or effort | Who pays and one-time or recurring |
|---|---|---|
| Catalog size and variant complexity | Large catalogs with many option combinations need more attribute mapping, validation and test imports. Confirm the export shape from Shopify's CSV before scoping. | In-house or partner labor, one-time |
| Image volume and re-import | Shopify's product CSV omits images, so images must be re-imported from public URLs. Keep the original store live until that import finishes and is verified. | Partner or in-house labor, one-time; storage and CDN bandwidth recurring |
| Number of Shopify apps to replace | Each app needs a Magento extension, a custom module or a removal decision. Extension licenses and vendor support fees are usually recurring, so compare them per app. | In-house or partner for build, extension vendors for license and support, recurring |
| Custom checkout logic | Checkout customizations written for Shopify must be rebuilt in Magento's checkout and payment model. Expect the most testing effort here. | Partner or in-house developers, one-time; maintenance recurring |
| Payment gateway and PCI scope | Each gateway integration, and how much card data touches your servers, sets the audit scope. Confirm with your assessor and gateway which responsibilities move to you. | Payment provider and partner for integration, one-time; PCI assessment and gateway fees recurring |
| Redirect volume | Every changed URL needs a mapped redirect to protect search traffic. Large legacy URL sets take longer to map and test. | In-house SEO or partner labor, one-time; redirect rule maintenance recurring |
| Hosting and performance tuning | Magento needs PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, nginx and Varnish for self-managed installs. Load testing drives sizing, so ask for a documented test plan. | Hosting provider and partner, setup one-time; infrastructure, monitoring and support recurring |
| Patching cadence | Adobe documents annual full patches for the 2.4.x LTS line and security patches at least annually. Each release also needs regression testing of your extensions, which the vendor may not cover. | In-house or partner for upgrades and testing, recurring; extension vendors for compatibility updates |
How the migration changes by store size and starting point
A single-brand catalog store is the most direct case. The main work is moving products, variants, customers and orders through CSV exports, then rebuilding the handful of apps and theme features the store relies on as Magento Open Source extensions. Product images are not included in the Shopify CSV, so the store is re-imported from public image URLs, and the original store should stay live until that step finishes.
- Data work: Product and customer CSVs cover most of the catalog, but the customer export is capped at 15 MB, so large customer bases need to be split into several files.
- Extension choices: Map each installed Shopify app to a Magento extension or a custom module, and confirm the extension's maintenance status against the 2.4.9 line before purchase.
- Cutover complexity: Usually the lowest of the three, because the catalog is one store with one currency and one set of URLs to redirect.
- Search and cache: Plan OpenSearch 3 and Varnish 8 for self-managed hosting, since both are listed in the requirements for the 2.4.x line.
- Redirects: Build a complete old-to-new URL map before cutover so product and collection URLs keep their search rankings.
Confirm with the platform team which Shopify apps carry real revenue, and whether the store's theme needs a custom Magento theme or a supported base theme before work begins.
A store selling across several countries or brands needs a Magento multi-store structure with separate websites, store views and currencies. Shopify Markets handles some of this for you today, so the migration has to rebuild that logic explicitly. Data work multiplies because prices, tax settings, languages and inventory may differ by market, and the exports need to carry those differences into the right scopes.
- Data work: Export and import prices, catalog rules and customer groups per website, and check that each market's currency settings are correct before importing orders.
- Extension choices: Multi-store setups depend more on payment, tax and shipping extensions that support per-website configuration, so confirm that each candidate supports this model.
- Cutover complexity: Higher, because each market may have its own domain, redirects, payment gateway and go-live date that must be sequenced.
- Shared versus separate data: Decide whether customers and catalog are shared across markets or separated, since this is hard to change after launch.
- Hosting footprint: Confirm whether one installation serves all markets or whether each brand runs its own, which changes the number of environments to patch.
Confirm with the platform team the exact market list, the tax and currency rules for each, and whether any market needs a separate legal entity or payment processor.
A store with B2B pricing, company accounts, net terms or custom Shopify Functions has logic that does not move in a CSV. Company hierarchies, negotiated price lists, approval rules and checkout customizations must be rebuilt as Magento features, extensions or custom code. This is where the migration scope grows most, and where the outcome depends on how much of that logic the team chooses to keep.
- Data work: Company accounts, contacts, price lists and tiered pricing usually need a separate mapping exercise and a test import, since standard exports do not capture every B2B relationship.
- Extension choices: Compare native Magento B2B capability in Adobe Commerce with open-source options, and note that some B2B features are paid editions. Confirm which features your Open Source build will include.
- Checkout logic: Each Shopify Function must be replaced by a Magento plugin, observer or custom module, and tested against the checkout flow and payment gateway.
- Cutover complexity: Highest of the three, because pricing rules, customer approvals and order history must be validated before the store opens to trade accounts.
- Ongoing ownership: Custom code adds upgrade work at every 2.4.x release, so budget for regression testing.
Confirm with the platform team an inventory of every Shopify Function, script and B2B rule in use, and decide early which ones are worth rebuilding and which should be retired.
What usually goes wrong in a Shopify Plus to Magento migration
Most failed cutovers trace back to a handful of gaps that were visible during planning but not closed in time. The cards below cover URLs and search equity, images, customer accounts, payments, extensions and performance, with a prevention step for each. Treat them as a checklist for your migration plan, not as a forecast of your project.
Broken URLs and lost search equity
Shopify product, collection and page URLs rarely match Magento's URL rewrite patterns, so every changed path becomes a 404 unless it is mapped. Build a complete old-to-new redirect map from the full Shopify URL list, including collections, tag pages, paginated listings and legacy paths, before DNS moves. Validate it against a crawl of the live store and monitor 404s in search console for weeks after cutover. Ask your integrator to show the redirect source and test results in writing.
Images missing after cutover
Shopify's product CSV does not include images, so a catalog moved by CSV alone launches with blank product pages. Images must be re-imported from their public URLs, which only works while the original store still serves them. Keep the Shopify store live until the image import completes, then check file names, alt text and variant image assignments against a sample of products. Plan for image resizing and cache warming in the Magento build, not only the transfer.
Customer account and password gaps
Customer CSV exports carry profile details, tags and supported metafields, but they do not give you usable login credentials for Magento. Shoppers may face forced password resets, which lowers repeat purchase rates if the reset flow is slow or confusing. Confirm with your team how password hashes are handled, whether a reset email template is ready, and which account fields map to Magento customer attributes. Export customers within the file size limit and check for duplicate emails before import.
Payment gateway and PCI scope surprises
Payment setup is often treated as a configuration task, yet a self-hosted store takes on card data handling that Shopify previously carried. Gateways must be configured, tested in sandbox and switched to production with webhooks, tokenization and 3D Secure verified end to end. Ask your QSA or assessor to define the PCI scope of the Magento servers, admin access and any custom checkout code before go-live. Document who owns each payment credential and rotation schedule.
Underestimated extension rebuild work
Shopify apps and themes do not transfer, and many merchants discover late that a feature they rely on needs a Magento extension, a custom module or a paid license. Inventory every installed app, including those that run checkout, tax, shipping rates, B2B pricing and subscriptions, and classify each as replace, rebuild or drop. Check each Magento candidate against your Magento version and its update cadence before committing. Budget testing for every rebuilt checkout rule, since these are the most expensive to get wrong.
Performance failures under load
A catalog-heavy Magento store without tuned full-page caching and search indexing can slow sharply during promotions, even when it passed functional testing. Self-managed installations use Varnish for full-page caching, and Magento's search depends on OpenSearch, so both need configuration and capacity tests before launch. Run a load test at your peak expected traffic against a production-like stack, and confirm the Redis or Valkey and RabbitMQ services are sized for queue and session volume. Agree ownership of these services in your runbook.
Questions buyers ask before moving from Shopify Plus to Magento Open Source
How much does a move from Shopify Plus to Magento Open Source cost?
The software license is free, so the cost is the work around it. Magento Open Source source files are licensed under OSL-3.0, so there is no license fee to pay Adobe, but you pay for the people and services that build, host and maintain the store. The main components are the build and data migration, theme and storefront work, replacing Shopify apps with extensions, hosting and CDN, payment and PCI scope, and ongoing patching and support. Most of this is one-time project work, while hosting, extension licenses, security patching and support recur every year. Ask any provider for a quote that lists each component separately, states which extensions are paid, and names who holds the hosting and patching responsibility after launch. DeployOpen provides fixed-scope quotes that follow from a written scope.
How long does a Shopify Plus to Magento Open Source migration take?
The timeline depends mainly on catalog size, the number of Shopify apps to replace, custom checkout logic, and how many integrations (ERP, shipping, tax, payments) must be rebuilt. A catalog-heavy store with many variants and custom metafields takes longer to map and validate than a simple store. Image handling also adds time, because Shopify's product CSV does not include images, so they must be re-imported from public URLs. Ask for a timeline in the written scope that breaks out data mapping, extension selection, theme build, testing, payment setup and cutover, and ask which of those steps depend on decisions you have not made yet.
What does the merchant team need to provide during the migration?
Your team needs to make business decisions and supply access. Someone must own the product data model, define how variants, collections and metafields map to Magento attributes, and approve which Shopify apps are replaced and which are dropped. You will also need admin access to Shopify, the payment and shipping accounts you plan to keep, your tax and ERP contacts, and sign-off on URL redirects and test cases. Without these decisions made early, scope changes tend to appear late in the project, when they cost more to absorb. Confirm in the scope document which of these tasks the provider performs and which stay with your staff.
Can an in-house team run the migration without an outside partner?
An in-house team can do it if it already has Magento or PHP development skills, has operated a self-hosted application, and can staff ongoing patching. Magento Open Source runs on a stack of PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, Composer and nginx, and Adobe supports only listed combinations, so the operational footprint is larger than a hosted store. Teams without this experience usually bring in a partner for the build, the data migration and the hardening, then keep the operation in house or on a retainer. Compare the skills you have with the list in Adobe's system requirements before deciding, and ask a partner to show which tasks it would hand over to you.
How does Magento Open Source support and patching work?
Each 2.4.x release gets three years of standard support from general availability, according to Adobe's lifecycle policy. Adobe lists end of regular support for 2.4.6 on August 11, 2026, for 2.4.7 on May 31, 2027, for 2.4.8 on May 31, 2028 and for 2.4.9 on May 31, 2029. Adobe also states that a full patch for the 2.4.x LTS line ships annually in May, and security patches ship at least annually for all supported lines. Plan upgrades around those dates, since each upgrade also means checking PHP, database and search versions against the system requirements. Ask your provider which release line it will target, who runs the upgrades, and how security patches are tested before deployment.
How do I keep Shopify live during the transition?
Keep the Shopify store running until the new Magento store is verified, because Shopify advises keeping the original store live until images have been imported from their public URLs. Export products, customers and orders from Shopify's admin as CSV files, noting that customer exports are limited to 15 MB, and use the Admin API where CSVs fall short, such as metafields or full order history. Run both stores in parallel for testing, set up redirects for every indexed URL, and cut over DNS and payments in a planned window. Ask your provider how it will handle order history continuity and customer logins during cutover.
What is the difference between Magento Open Source and Adobe Commerce?
Magento Open Source is the free, self-hosted edition, while Adobe Commerce is Adobe's paid full-featured edition, sold on-premises, on Adobe's cloud infrastructure or as Adobe Commerce as a Cloud Service. The magento2 repository describes Open Source as providing basic ecommerce capabilities. Adobe positions Adobe Commerce with cloud hosting and AI merchandising, and its developer documentation covers both editions together. Features that some teams associate with Adobe Commerce, such as the clearCart GraphQL mutation, have moved into Open Source in recent releases, so check the release notes for the version you plan to use. Confirm feature by feature with Adobe before assuming a capability is missing.
What checkout and payment setup do I need to plan for?
Plan for payment gateway integration, PCI scope and content security policy. Magento Open Source supports Content Security Policy headers from 2.3.5, and from 2.4.7 CSP runs in restrict mode by default on storefront and admin payment pages, so payment scripts must be allowed explicitly. You are responsible for hosting, patching and the environment in which card data is handled, which changes your PCI responsibilities compared with a hosted checkout. Ask your provider for a written payment and checkout plan that names the gateway, the hosting model and the evidence it will produce for your assessor. DeployOpen prepares controls and evidence for compliance assessments but does not issue audit reports or certifications.
Official sources for Magento Open Source and Shopify export behavior
Start from Shopify's own export documentation before you plan the import, because what the admin exports sets the scope of your data work. The product CSV exported from the Shopify admin does not include product images, so Shopify advises keeping the original store live until the new store has imported images from their public URLs. Treat that overlap as a planned cost and a cutover checklist item, and confirm that every image URL still resolves before you switch DNS. Read the Shopify product export guide alongside the customer import and export article, because the customer CSV is limited to 15 MB and includes tags and supported metafields. Large customer bases will need several files, and metafields outside the supported set will need a separate extraction path.
Pin your target to a Magento Open Source release line whose support dates match your planning horizon. The 2.4.9 release notes state that Magento Open Source 2.4.9 was released in May 2026, with official support for PHP 8.5 and Symfony 7.4 LTS, and that the clearCart GraphQL mutation, previously Adobe Commerce only, is now available in Open Source. Read the Magento Open Source 2.4.9 release notes against your extension list, since an extension that depends on the old behavior will need retesting. Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability, so confirm the end dates for the line you choose before you approve a support plan.
How DeployOpen scopes, runs and supports the migration
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Shopify Plus move to Magento Open Source, we work from a written scope that covers catalog export, image re-import, extension rebuilds, redirects and payment setup before any build starts.
How we scope
- Inventory the Shopify Plus catalog, customers, orders, apps, themes and checkout customizations before agreeing on any build work.
- Agree in writing which products, variants, metafields and order history will move, and which will be reviewed by hand.
- Define the Magento Open Source version, hosting model and extension list, and confirm them against the current system requirements.
How we build
- Script product, customer and order imports and test them against a staging copy of the catalog before cutover.
- Re-import product images from their public URLs and verify that each image resolves on the new store.
- Rebuild required app functions as Magento extensions, configure payment gateways and set up URL redirects from the old store paths.
How we hand over
- Document the architecture, deployment steps, redirect map, data mapping and rollback procedure for your own platform team.
- Walk through the admin, catalog, order and payment workflows with the staff who will run the store every day.
- Keep the original Shopify Plus store live until the new store has completed image import and verification checks.
How we support
- Ongoing support, upgrades and continuous security testing are available as a retainer after handover.
- Plan upgrades around Adobe's published support windows for each 2.4.x release and its security patch cadence.
- Confirm with your team who owns PHP, database, search, cache and PCI scope responsibilities once the store runs on your infrastructure.
