Migrate from Salesforce Commerce Cloud to Magento Open Source: what the move involves
Moving from Salesforce Commerce Cloud to Magento Open Source is a re-platforming of catalog, price, customer, order and cartridge logic, not a data copy. Teams usually arrive here after a renewal, a licensing change, a data residency requirement or a lock-in concern, and the work is typically run by an internal platform team with an implementation partner who handles the storefront build, the integrations and the cutover. Magento Open Source is a platform you host and operate yourself, which is different from Adobe Commerce, the paid edition that Adobe sells on-premises or on its cloud. Confirm early which of the two your business case assumes, because licensing, hosting and support responsibilities differ between them.
The effort and risk concentrate in three places: rebuilding business logic that sits in SFCC cartridges as Magento modules, mapping Commerce Cloud sites and price books onto Magento websites, store views and customer groups, and re-integrating the CRM, payment, tax and order management systems that currently receive data from Commerce Cloud. Start with an inventory of every cartridge hook, scheduled job and custom attribute, then decide which ones Magento already provides and which need an extension. Ask your implementation partner for a written list of the modules they plan to build or customize, and for the test approach that covers price calculation, promotions and checkout before any cutover date is set.
Plan the operating model as carefully as the build. Magento Open Source runs on a stack that you must install, patch and scale: the Adobe system requirements for the 2.4.9 release list PHP 8.5, MySQL 8.4 or MariaDB, OpenSearch 3, Redis or Valkey, RabbitMQ and nginx, and Adobe supports only the listed combinations. Under Adobe's lifecycle policy, each 2.4.x release has three years of standard support, so confirm which line you will run and when it reaches end of regular support. Full-page caching is handled by Varnish in self-managed installations, so the caching design must be part of the hosting plan. Ask your partner to price these recurring costs separately from the one-time build, and confirm who holds the on-call and patching obligations after go-live.
Which Commerce Cloud capabilities map cleanly to Magento Open Source
This table compares common Salesforce Commerce Cloud capabilities with their closest Magento Open Source equivalents and marks each as clean, needs rework or gap. Use it to scope the build before you commit to a migration plan. Multi-site and price book scale must be confirmed against the Magento edition and hosting model you choose, because the open-source distribution and the paid Adobe Commerce edition differ in features.
| Commerce Cloud capability | Magento Open Source equivalent | Status |
|---|---|---|
| Catalog, categories and products | Native catalog with categories, simple, configurable and bundle product types, exported from SFCC XML and imported through Magento's data tools | Clean |
| Price books | Mapped to customer groups and catalog price rules, with a scripted import; large numbers of price books need load testing | Needs rework |
| Sites and locales | Sites map to websites, with store views per language or region; confirm site count limits with your edition | Needs rework |
| Customer accounts and groups | Core customer accounts and customer groups carry over; SFCC password hashes and custom attributes need a verified import path | Needs rework |
| Promotions and coupons | Cart price rules and coupon codes cover common cases; complex SFCC promotion logic typically needs custom extensions | Needs rework |
| Multi-currency | Supported through store view currency settings; confirm exchange rate handling for your markets before go-live | Needs rework |
| Search | Magento uses OpenSearch in the listed system requirements; relevance tuning and synonyms must be rebuilt and retested | Needs rework |
| Caching and full-page cache | Varnish is the documented full-page cache for self-managed installs; cache rules replace SFCC cache settings | Needs rework |
| CRM and order management integrations | Built as Magento APIs, events and custom integrations to your CRM and order management system; no native one-to-one equivalent to SFCC integrations | Gap |
| Cartridge customizations | Cartridge code is rewritten as Magento modules and extensions; no automatic conversion from cartridges | Gap |
Which data and integrations move, and through which export path
A Commerce Cloud move splits into export units: catalog, price books, customers, orders, coupon codes and site configuration. Each unit has its own export path, its own import route in Magento Open Source, and its own checks before cutover.
Catalog and price books
Export the catalog, categories and price books from Business Manager as XML, then map them to Magento products, attribute sets and categories. Magento Open Source prices through customer groups, catalog price rules and store-level settings, so each Commerce Cloud price book needs a named equivalent before import. Confirm with your implementation partner which price book structures need a custom extension, and check product counts and variants after every test import.
Customers and password handling
The customer export carries profiles, addresses and group membership, which map to Magento customers and customer groups. Credentials need a separate decision: ask Salesforce which password data the export includes and whether it can be used by Magento's authentication. If passwords cannot move, plan a reset flow and communicate it to shoppers before the cutover date. Test login for each customer group in staging.
Orders as history
Order exports are usually imported as read-only history for customer accounts and service teams, not as live orders that Magento must fulfill. Confirm which statuses, payment references, shipments and returns the export contains, and decide where open orders finish: in Commerce Cloud until settled, or in the new store with a clear cutover rule. Keep order numbers traceable between the two systems so support can find both records.
Coupon codes and site configuration
Coupon codes, promotions and site preferences are separate export units. Export coupon codes with their usage limits and validity dates, then rebuild the matching cart rules in Magento. Commerce Cloud sites map to Magento websites and store views, so each site's locale, currency, tax and shipping settings need a documented target. Confirm the export format for each unit in Salesforce's current documentation before writing any transform.
Images and the source store
Product images usually sit outside the catalog export, so they need their own copy step and a check that every product still resolves to an image. Shopify's documented rule is a useful pattern here: keep the original store live until the new store has imported images from their public URLs. Apply the same rule to Commerce Cloud, and keep the old storefront running until image coverage, redirects and product URLs have been verified.
CRM and order management connections
Commerce Cloud integrations to CRM, order management and payment services are not copied into Magento. Each connection is rebuilt against Magento's REST and GraphQL APIs or its message queue, with its own authentication, error handling and retry rules. List every inbound and outbound integration from the current estate, assign an owner for each, and test order, customer and refund events end to end before go-live.
How the migration runs from inventory to decommission
The sequence moves a Commerce Cloud estate to Magento Open Source in controlled stages, so each site, price book and customer record is proven on a pilot before any production traffic moves. Each phase ends with a named artifact that the next phase depends on.
Inventory sites, price books, cartridges and integrations
Your team and the implementation partner list every site, locale, currency, price book, promotion, custom cartridge, scheduled job and integration that touches Commerce Cloud, including the CRM, order management, payment, tax and shipping connections. Each item is tagged with an owner and a disposition: rebuild as a Magento extension, replace with a configuration setting, retire, or keep outside the platform. Confirm the list with merchandising, finance and customer service before estimating work. The step is done when the inventory is signed off and every cartridge has a rebuild or retire decision.
Build a pilot site on Magento Open Source
Choose one low-risk site or market and stand up a Magento Open Source instance in your own cloud account or data center, with the supported PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, nginx and cache versions listed for the release you select. Map that site's sites, price books and catalog to websites, store views and customer groups, and rebuild its cartridge logic as extensions. Confirm version support dates with Adobe before you lock the release line. The pilot is complete when a test order can pass from storefront to payment to the order record, with the cache and search services running as they will in production.
Extract data and rehearse the mapping
Export catalog, categories, customers, orders and coupons from Commerce Cloud using the XML exports and the site import and export tooling, then convert them into Magento's import formats with scripts your team can version. Run the full extraction against a staging copy several times, logging every record that fails validation, such as missing attributes, unmapped tax classes or duplicate customer emails. Agree with your team how passwords and customer tokens are handled, because they usually do not transfer in readable form. The rehearsal is done when two consecutive runs produce the same record counts and the exception log has an owner for each open item.
Run a parallel period with reconciliation
Keep Commerce Cloud live as the system of record while the Magento site runs alongside it for the pilot market, with orders and customer changes reconciled between the two each day. Compare order totals, tax, shipping, inventory positions, customer registrations and promotion usage, and track every difference to a cause. Involve finance and customer service in reviewing the reconciliation reports. The step is complete when the differences are explained and the reconciliation has run cleanly for the period you agreed in writing with your project lead.
Cut over with a DNS and redirect plan
Prepare a written cutover runbook that covers the final delta export, DNS changes, TLS certificates, the Content Security Policy headers Magento applies to payment pages, cache warm-up, and the URL redirect map from old Commerce Cloud paths and SEO URLs to the new store views. Freeze catalog and price changes during the window, then switch traffic and run smoke tests on checkout, login, search and the CRM hook. Keep the old storefront reachable for rollback. The cutover is done when the smoke tests pass, redirects return the expected status for a sampled URL list, and payment transactions complete on the new store.
Decommission Commerce Cloud after the retention period
After the retention period in your contract and data policy ends, export a final archive of orders, customers and configuration for records retention, confirm that all integrations point to Magento, and revoke Commerce Cloud API credentials and job schedules. Your compliance lead should confirm where the archive is stored, who can access it and how deletion is evidenced. Record the decommission in your asset register and update the runbooks for the Magento estate. The step is done when the archive is verified, access is revoked and the decommission record is signed by the business and technical owners.
What drives cost and duration in this migration
This table lists the main drivers that change the cost and timeline of moving from Salesforce Commerce Cloud to Magento Open Source, why each matters, and how to keep it manageable. Read it as a checklist for scoping and for the questions to put to any implementation partner before a quote is accepted.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Number of sites and locales | Each Commerce Cloud site becomes a website or store view in Magento, and each locale adds catalog, content, tax and URL work. Sites that share little data multiply the mapping effort. | Confirm which sites are truly separate brands and which are locales of one store. Merge where the business allows and phase the rest. |
| Price book complexity | Price books map to customer groups, catalog price rules and store-level pricing. Overlapping books, schedules and currency rules need explicit translation and testing. | Export and count active price books before scoping. Retire unused books and agree the pricing model with finance before mapping starts. |
| Cartridge logic rebuilt as extensions | Custom cartridge code has no direct equivalent in Magento. Each hook, pipeline and controller must be rewritten as a module, which is usually the largest engineering item. | Inventory every cartridge feature, then remove features nobody uses. Prefer Magento core or existing extensions before writing custom modules. |
| CRM and order management integrations | Salesforce, order management and fulfillment connections carry data in both directions. Field mapping, retries and reconciliation all need build and test time. | List every integration and its data flows early. Define the system of record for orders, customers and stock before design begins. |
| Personalization replacements | Commerce Cloud personalization and recommendation features may not exist in Magento Open Source in the same form. Replacement may need a third-party service or custom code. | Confirm which personalization features are used in production. Decide early whether each one is replaced, dropped or hosted elsewhere. |
| Data quality | Duplicate SKUs, incomplete customer records, legacy URLs and inconsistent attributes slow imports and create defects after go-live. Cleaning usually takes longer than the import itself. | Profile the XML exports before scoping. Agree cleanup rules with merchandising and customer service, and keep a URL redirect map from the start. |
| Hosting and performance testing | Self-managed Magento needs the stack in the supported list for the chosen release, such as PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, nginx and Varnish. Load tests must reflect peak trading periods. | Pick a release on the official lifecycle, such as 2.4.9, and check the system requirements for it. Budget load testing as a separate, recurring activity before peak seasons. |
| In-house staffing | Running Magento requires ongoing skills in PHP, indexing, caching, security patching and release upgrades. Staff cost recurs for the life of the store. | Ask which roles will be internal and which will be contracted. Plan knowledge transfer and documented runbooks as deliverables. |
| One-time versus recurring costs | One-time costs include discovery, data mapping, extension development, migration rehearsals and launch. Recurring costs include hosting, licenses or support contracts, security patching, upgrades, testing and staff. | Ask every quote to split these two categories. Ask for hosting and support costs over a stated period, not only the build fee. |
| Items to ask for in a quote | A quote is only comparable if it states scope, assumptions and exclusions. Missing exclusions are the most common source of later change requests. | Request a written scope covering sites, price books, cartridge features, integrations, data volumes, testing, go-live support and handover. Confirm timelines and fees in writing from the provider. |
How the work differs by starting point and estate size
A single-site Commerce Cloud estate usually maps to one Magento Open Source installation with one website, one store and one or more store views, such as separate language or currency presentations. Most of the work sits in the catalog, customer and order data, plus a rebuilt storefront. Price books are the main mapping question: a single price book often becomes one set of catalog prices, but any site-specific or customer-group pricing must be recreated with Magento's pricing and customer group features.
- Catalog mapping: Map Commerce Cloud categories, attributes and variation models to Magento categories, attributes and configurable products before any import runs.
- Customer groups: Recreate customer segments as Magento customer groups and confirm how password hashes are handled before moving accounts.
- Testing: Run a checkout, tax, shipping and promotion test pass against a copy of the production catalog and a representative order set.
- Parallel running: Keep the Commerce Cloud site live for orders during cutover, then freeze catalog changes for a short, agreed window.
- Store views: Use store views for language or presentation differences only when the catalog and pricing are identical across them.
Confirm with your team how many sites, locales and price books the estate actually runs, because that count decides whether a single installation is enough.
Estates that run several brands or regional sites on one Commerce Cloud organization need an earlier architecture decision. In Magento Open Source, websites, store groups and store views separate presentation and some configuration, but a single installation shares one catalog base, one set of order statuses and one administrative user model. If brands need separate catalogs, separate tax rules, separate payment accounts or separate admin access, a multi-installation design is often easier to govern, and each installation then carries its own hosting, patching and integration cost.
- Shared versus separate catalogs: Decide whether brands share products with different prices, or whether each brand owns its own catalog, before mapping begins.
- Currencies and tax: Confirm each region's currency, tax and payment requirements, since these drive whether store views are enough.
- Testing per site: Test each brand or region separately, including locale-specific shipping and address validation.
- Parallel running: Migrate one brand or region first where possible, so the team learns the pattern before the largest site moves.
- Governance: Document which admin users can change which websites, because shared installations make that access broader.
Illustrative example: a retailer with two brands that never share products may find two installations simpler to operate than one installation with many store views and custom access rules.
Estates with many custom cartridges carry business logic that has no direct equivalent in Magento. Each cartridge hook, pipeline, custom object and scheduled job must be inventoried, classified and either rebuilt as a Magento module, replaced by a standard feature or retired. This is usually the largest source of effort and risk, and it does not show up in a data export. Testing shifts from data reconciliation toward regression tests for each business rule the cartridges enforce.
- Inventory: List every cartridge, job, custom attribute and integration endpoint, and mark which ones matter to revenue or compliance.
- Rebuild as modules: Write Magento extensions for logic that must stay, and review whether each one can be replaced by a maintained community extension.
- Regression suites: Automate tests for pricing, promotions, tax, checkout and payment flows before the first import.
- Parallel running: Run both platforms against the same test orders for a period, comparing totals and tax lines.
- Upgrade cost: Each custom module must be retested on every Magento minor release, so count that recurring work in the plan.
Ask your implementation partner for a written inventory of cartridge logic, with an estimate of what is reused, rebuilt or dropped, before agreeing a fixed scope.
Some Commerce Cloud estates run a packaged order management system alongside the storefront, handling fulfillment, returns, warehouse routing or customer service. Magento Open Source covers basic order handling, but a packaged OMS may hold order history, stock allocation and returns logic that must continue to work after cutover. The migration question becomes whether Magento keeps those responsibilities, the OMS is reconnected to Magento, or both are replaced by another system. Parallel running is harder because two systems may write to the same order record.
- Ownership of order state: Decide which system is the source of truth for order status, shipments and refunds, and keep only one writer per field.
- Interface mapping: Map order, shipment, return and inventory messages between the OMS and Magento, and test every status transition.
- Historical orders: Agree how many years of order history move into Magento and how the OMS keeps the rest.
- Parallel running: Route new orders to one system at a time, with a rollback path, rather than splitting orders by region without a clear rule.
- Support teams: Confirm that customer service tools can still see orders from both systems during the transition.
Confirm the OMS vendor's interface and licensing terms in writing, because they determine whether the integration can be rebuilt in your own infrastructure.
What usually goes wrong and how to prevent it
Most failed Salesforce Commerce Cloud exits do not fail on the storefront launch day. They fail in the data and logic that moved quietly, such as prices, customer access, order history and redirects. The cards below name the failure points that recur in B2C migrations to Magento Open Source and the check that catches each one before cutover.
Price book mismatches
Commerce Cloud resolves a product price from price books assigned to a site, while catalog price rules and promotions can change the final figure at checkout. When the export maps price books to Magento store views and customer groups without matching these layers, shoppers see one price on a product page and another in the cart. Build a reconciliation sheet that compares a sample of SKUs per site, currency and customer group across both systems, and treat any difference as a blocker.
Lost customer credentials and consent
Customer exports carry profile data, but password hashes and consent records do not always move in a form Magento can verify. Shoppers who cannot sign in often abandon the account, and marketing consent recorded in the old system may not be carried over with its date and wording. Confirm with your engineers which credential fields can be imported, plan a password reset flow for those that cannot, and migrate consent records as their own dataset with timestamps.
Order history gaps
Order exports often include headers and totals but split line items, tax lines, shipping adjustments and payment references into separate files. Missing any of these breaks customer order lookup, returns and the finance reconciliation that follows. Agree on a target order record for Magento before extraction, load a set of completed orders with their refunds and partial shipments, and compare totals against the source ledger for each period.
SEO loss from missing redirects
Commerce Cloud URL patterns for products, categories and content pages will not match Magento's URL rewrites by default. Every indexed URL without a 301 redirect becomes a dead end for search engines and for bookmarks, and that loss often shows up weeks after launch. Export the full list of live URLs from search console data and server logs, map each to its Magento target, and load the redirects before DNS changes.
Payment and tax configuration errors
Payment gateways, tokenized card references, tax classes and tax rules are often configured in places the catalog export does not show. A missing gateway credential or a wrong tax class can allow orders to place but fail at capture, or charge the wrong rate for a region. Inventory every payment method, tax rule and shipping rate from Business Manager, then test each combination with live gateway sandboxes and a sample order per jurisdiction before go-live.
Underestimated cartridge rework
Cartridge logic for promotions, custom checkout steps, pipelines and integrations is written against Salesforce APIs and does not port one to one. Teams that plan only for the storefront theme often discover late that tax, shipping and promotion rules live in server-side code that now has to be rebuilt as Magento modules. Inventory every cartridge hook and custom pipeline in a written list, classify each as rewrite, replace with a standard feature or retire, and estimate each rewrite with the engineers who will maintain it.
Performance failures under load
Magento Open Source runs on infrastructure you build and operate, and the full-page cache, search index, queue and database all need sizing for peak traffic. Under a promotional spike, a cache miss or an unindexed search can slow checkout enough to lose orders. Load test the staging environment at your peak session and checkout volume, confirm the Varnish, OpenSearch and message queue configuration against the supported versions, and rehearse the cutover with a scaling plan.
Questions buyers ask before moving from Commerce Cloud to Magento
What drives the cost of moving from Commerce Cloud to Magento Open Source?
The largest cost drivers are the size of the catalog and number of sites, the number of cartridge behaviors that must be rebuilt as Magento extensions, the depth of CRM and order management integrations, and the hosting and performance work your traffic requires. Magento Open Source has no license fee, so the spend moves to the people and infrastructure that replace what Commerce Cloud provided. Costs fall into one-time items (data extraction, mapping, build, testing, cutover) and recurring items (hosting, security patching, upgrades, extension maintenance and support staff). Ask any implementation partner for a quote that separates these lines and states what is included in each phase.
How long does a Commerce Cloud to Magento migration take?
Duration depends on scope, so the most useful answer is the sequence of phases rather than a fixed period. The work typically runs through discovery and data inventory, mapping sites and price books to websites, store views and customer groups, extracting and transforming catalogs, customers and orders, rebuilding cartridge logic as extensions, re-integrating CRM and order management, then testing, parallel running and cutover. Each phase depends on the one before it, and the integration and testing phases usually carry the most uncertainty. Ask for a written plan with phase gates and the criteria that close each one.
What does our team need to provide during the migration?
Your team needs to supply business owners who can decide how price books, promotions, tax rules and customer segments map to Magento, access to Business Manager exports and the systems that consume them, and engineers who understand the current cartridge code. You will also need people to own the CRM, ERP and order management integrations, to sign off test cases and to approve the cutover plan. Without these named owners, decisions stall and the schedule slips. Confirm the availability and the decision rights of each person before work starts.
Can our in-house team migrate Commerce Cloud to Magento without a partner?
An in-house team can do this if it already has Magento or PHP engineers, experience with Magento's module and theme structure, and operations skills for search, caching, queues and database hosting. Most gaps appear in performance tuning, payment and tax integrations, and the testing needed to prove that orders, customers and pricing match the source system. Assess the skills you have against each phase before deciding, and consider a fixed-scope partner engagement for the parts you cannot cover. DeployOpen plans, implements and hardens self-hosted platforms in your own infrastructure under written scope.
How long does Magento Open Source 2.4.x receive support?
Adobe gives each 2.4.x release three years of standard support from general availability. The published end-of-regular-support dates are August 11, 2026 for 2.4.6, May 31, 2027 for 2.4.7, May 31, 2028 for 2.4.8 and May 31, 2029 for 2.4.9. Adobe also states that a full patch for the 2.4.x LTS line ships annually in May and that security patches are released at least annually for all supported lines. Plan your upgrade path around these dates and confirm the current status on Adobe's lifecycle page before you pick a starting version.
What is the difference between Magento Open Source and Adobe Commerce?
Magento Open Source is the free edition, with source files licensed under OSL-3.0 and AFL 3.0 included in the distribution. Adobe Commerce is Adobe's paid edition, which Adobe positions as the full-featured option with cloud hosting and AI merchandising. Adobe's developer documentation covers both together, so features, support terms and some configuration steps differ by edition. Before you commit, list the Commerce features you rely on today, such as B2B functionality or advanced merchandising, and confirm with Adobe which of them exist in Open Source and which require a paid license.
What should we confirm with Adobe and in our own environment before committing?
Confirm with Adobe the support window for the version you plan to run, the supported combinations of PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, Composer and nginx for that release, and whether your required features are in Open Source. In your own environment, confirm your hosting region and data residency needs, the traffic peaks you must absorb, how payment, tax and ERP systems connect, and whether you need Varnish as a self-managed page cache. Ask Adobe's documentation and your partner to show these in writing so the decision rests on verified facts.
What recurring work comes after go-live on a self-hosted Magento store?
After go-live, recurring work includes applying security and minor patches, upgrading to supported 2.4.x releases before end of regular support, updating extensions and themes for compatibility, monitoring performance and search, and maintaining backups and disaster recovery. Each Magento upgrade also requires regression testing of custom code and integrations. These tasks can be handled by your own staff or by a retainer for ongoing support, upgrades and testing. Ask for a quote that lists the patch cadence, upgrade responsibilities and the hours or service levels included, and confirm them in writing.
Which Magento Open Source release to target and how long it stays supported
Target a release line whose support window covers the whole migration plus the years after go-live. Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability, with end of regular support on August 11, 2026 for 2.4.6, May 31, 2027 for 2.4.7, May 31, 2028 for 2.4.8 and May 31, 2029 for 2.4.9. Based on those dates, 2.4.9 is the line to plan around for a project that will go live later in the current cycle, because it has the longest runway. Adobe ships a full patch for the 2.4.x LTS line each May, and security patches at least annually for every supported line, so budget for an annual upgrade cycle rather than a one-off install. Check the Adobe Commerce lifecycle policy and the released versions page before you fix the target, since new patch releases appear in that list.
The 2.4.9 requirements define the stack your hosting team must provide. Adobe lists 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, and it supports only the combinations it lists. Confirm each component against your own platform and operating system images, your managed database or search service options, and your change windows for PHP runtime upgrades. For self-managed installations, Adobe documents Varnish as the full-page cache accelerator, while cloud-hosted Adobe Commerce uses Fastly instead, so a self-hosted estate must plan and operate Varnish itself. Varnish 8 is listed in the 2.4.8-p5 requirements, so confirm the Varnish version against the release you select in the system requirements.
Security headers change how your storefront and admin behave, so test them before cutover. Adobe's developer documentation says Content Security Policy headers are supported 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 payment, tag manager or chat script that loaded freely on the Salesforce storefront may now be blocked until its origins are allowed. Inventory every external script and frame in the current SFRA or PWA Kit storefront, map each to a CSP directive, and run those checks in staging with the same version you will launch. Ask your team to record which payment flows were tested under restrict mode, because a blocked payment page is a launch risk that no catalog import will reveal.
How DeployOpen scopes, runs and supports the migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts or data centers. For this migration, we start with a written scope that maps your sites, price books, customer data and integrations to Magento Open Source before any build work begins.
How we scope
- Inventory every Business Manager site, price book, catalog and customer segment that must map to Magento websites and store views.
- List each cartridge behavior and classify it as core Magento, an existing extension, or a custom module to write.
- Agree the CRM, order management and payment integrations in writing, with named data owners and cutover responsibilities.
- Confirm the target hosting environment, including Varnish or other cache layers, OpenSearch, Redis or Valkey and RabbitMQ versions.
How we build
- Build export and transformation scripts for catalogs, customers and orders, with reconciliation reports for each load.
- Rebuild storefront and checkout logic as Magento extensions, keeping custom code limited to what the written scope requires.
- Configure content security policy, admin access controls and payment page settings as part of the hardening baseline.
- Test catalog, pricing, tax, checkout and integration flows in a staging environment that mirrors production versions.
How we hand over
- Deliver architecture, configuration, runbooks and data mapping documents so your team can operate the store without us.
- Document the upgrade path for each Magento patch and minor release, including PHP and database version changes.
- Run knowledge transfer sessions with your platform, commerce and security staff against the delivered documentation.
- Provide compliance-readiness evidence for your own auditors, while noting that DeployOpen does not issue audit reports or certifications.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, security patching, upgrades and continuous testing are available as a retainer after go-live.
- Ask for a written quote based on your scope, since DeployOpen does not publish a price list.
- Confirm with DeployOpen which support hours, response commitments and upgrade responsibilities the retainer includes.
