How to Perform Adobe Commerce Data Migration in 2026: Smarter Import & Export for Better Results

Adobe Commerce data migration often involves much more than simply moving a CSV file from one system to another. Product catalogs, customers, pricing, inventory, categories, and other business data may need to be transferred regularly, transformed into the required structure, or synchronized with external platforms. Although Adobe Commerce offers more advanced import and export capabilities than Magento Open Source, including support for scheduled data transfers, its native functionality still has important limitations.

In this article, we explore how to improve Adobe Commerce import and export workflows and make data migration more flexible and reliable. You will learn how to work with various file types (XML, JSON, Excel, etc.) and sources (Google Drive, Google Sheets, FTP, API), transfer orders, categories, B2B, and other entities, automate recurring operations, and so on, overcoming the limitations of the default tools.

But before going any further, let’s look at the native Adobe Commerce import and export functionality and explain how it supports various Adobe Commerce data transfer scenarios.

Default Adobe Commerce Import & Export: What Can It Handle?

Before looking at ways to improve Adobe Commerce data migration, it is important to understand what the platform can already do out of the box. Adobe Commerce includes native import and export tools for bulk data transfers, as well as a scheduled import/export mechanism that is unavailable in Magento Open Source.

Default Adobe Commerce Importer Overview

The core data transfer tools are available under System > Data Transfer in the Adobe Commerce Admin. From here, administrators can run manual imports and exports or configure recurring jobs through Scheduled Imports/Exports.

Adobe Commerce can import all standard product types and product images, while the product import mechanism can also work with complex product data such as categories, websites, custom options, tier prices, related products, upsells, cross-sells, and associated products.

For a standard manual Adobe Commerce import, the platform expects data to follow its predefined structure. Manual imports support CSV files and compressed CSV files in ZIP archives, while native exports are generated as CSV. Adobe specifically recommends using exported data or downloadable sample files as templates because column headings need to correspond to Commerce attribute codes and expected service fields.

Depending on the entity, the importer provides behaviors such as Add/Update, Replace, and Delete. This means you can add new records, update existing information, replace existing entities with data from the import file, or remove records identified in the file. Adobe Commerce also validates the file before processing it and lets you stop the operation when errors occur or skip invalid entries within the configured error threshold.

Manual imports have their own history under System > Data Transfer > Import History. Adobe Commerce records information such as the start time, administrator, execution time, imported file, error file, and a summary of created, updated, or deleted records.

Native export works in the opposite direction. You can select a supported entity, filter records by attribute values, exclude unnecessary attributes, and generate a CSV file that can be opened in a spreadsheet, modified, and later imported back into Adobe Commerce. Export processing is asynchronous, so administrators can continue working in the backend while the file is generated.

Adobe Commerce also adds Scheduled Import/Export, an Adobe Commerce-exclusive feature that is not included in Magento Open Source. Scheduled jobs are managed by cron and can run daily, weekly, or monthly. Import files can be retrieved from the local Commerce server or a remote FTP server, and scheduled exports can be delivered to the same types of locations.

What Data Migration Scenarios Does the Default Importer Support?

According to the current Adobe Commerce documentation, the default importer supports the following entity types:

For basic Adobe Commerce data migration, the native tools can be perfectly adequate. Their strongest use case is a structured, CSV-based data transfer where the source data has already been prepared according to the Adobe Commerce format.

For example, you can use the default importer to move a product catalog from another system after transforming the source data into an Adobe-compatible CSV. Existing products can then be updated in bulk, while new SKUs can be created through the same operation. Product images can also be associated with imported products.

The native tools are similarly useful for transferring customers and customer addresses, updating advanced pricing, working with customer finance data, and transferring stock source information. Advanced pricing can be exported, modified in a spreadsheet, and imported again to update tier and group pricing without replacing the complete product record.

Another common scenario is a recurring file exchange. Suppose an external system generates a properly structured product CSV every night and places it on an FTP server. Adobe Commerce can retrieve that file through a scheduled import without requiring an administrator to upload it manually each time. The same principle applies to scheduled exports that need to be delivered periodically to another system.

Therefore, the native functionality works particularly well when three conditions are met: the required entity is natively supported, the incoming data already matches Adobe Commerce’s expected CSV structure, and the workflow relies on local storage or FTP with relatively simple scheduling requirements.

For these scenarios, installing an additional data migration solution may not be necessary.

What Adobe Commerce Data Migration Scenarios Cannot the Default Importer Support?

The limitations become much more visible when Adobe Commerce data migration goes beyond a prepared CSV file.

First, file format support is restrictive. Adobe Commerce does not natively let you feed arbitrary XML, JSON, XLSX, or ODS files into its standard importer. Export is also limited to CSV. If a supplier, ERP, PIM, CRM, or another ecommerce platform provides data in a different format, it normally has to be transformed before Commerce can process it.

The same problem applies to data structure. The default importer expects the file to follow Adobe Commerce’s predefined columns and data conventions. There is no flexible native mapping layer that lets you simply say, for example, that a supplier’s product_code column corresponds to Magento’s sku, or transform incoming values automatically as part of the import job.

Source connectivity is another limitation. Scheduled imports work with a local server or remote FTP, but they do not provide direct connections to services such as Google Sheets, Google Drive, Dropbox, OneDrive, or arbitrary URLs, nor does the standard importer provide a configurable REST/SOAP API connection for retrieving external data.

Entity coverage is also limited. Although categories can be assigned and even created as part of product import, there is no dedicated native category import entity. The standard import list likewise does not provide dedicated entities for orders, CMS pages and blocks, product attributes, reviews, URL rewrites, newsletter subscribers, catalog and cart price rules, and many other types of Commerce data. Native B2B data migration is similarly restrictive when you need to transfer entities such as companies, shared catalogs, requisition lists, or negotiable quotes.

Automation is useful but basic. Native schedules are limited to daily, weekly, or monthly execution. More specific cron patterns, multiple external sources, extensive transformation rules, sophisticated mapping, and complex integration workflows require additional tooling. Scheduled operations also do not maintain detailed execution logs for every run: Adobe Commerce provides failure emails and the latest outcome, while detailed per-job logging is not part of the scheduled import/export workflow.

This is where Improved Import & Export for Magento 2 and Adobe Commerce becomes useful. Let’s compare it with the platform’s default import and export solution.

Adobe Commerce Data Migration: Default Tools vs Improved Import & Export

The difference between native Adobe Commerce import and export and Improved Import & Export becomes especially clear when data migration grows beyond standard CSV transfers. While Adobe Commerce covers essential product, customer, pricing, inventory, and scheduled data transfer scenarios, Improved Import & Export expands the workflow with additional file formats, sources, entities, mapping tools, APIs, automation, and detailed logging.

How to Perform Adobe Commerce Data Migration with Smarter Import & Export

Native Adobe Commerce import and export is sufficient when your data already matches the platform’s requirements, and the migration consists of relatively straightforward CSV transfers. Real projects are rarely that simple. Source systems use different attribute names, category structures, file formats, storage locations, product relationships, and business logic. Data may also need to be migrated several times before launch or synchronized continuously after the initial transfer.

Improved Import & Export turns Adobe Commerce data migration into a configurable workflow rather than a sequence of manually prepared file uploads. You create reusable import and export jobs, connect them to external data sources, transform incoming information, map it to the Adobe Commerce structure, automate execution, and monitor the results from the same environment.

The extension currently supports Adobe Commerce on-premises and Adobe Commerce on Cloud Infrastructure (PaaS), as well as Magento Open Source. It is not designed for Adobe Commerce as a Cloud Service (ACCS), where traditional PHP extensions cannot be installed.

Let’s see how the improved Adobe Commerce import and data migration workflow works step by step.

Step 1: Create Adobe Commerce Import and Export Jobs

Improved Import & Export organizes data transfers into jobs. Instead of configuring every operation from scratch whenever data needs to be moved, you create a reusable profile for a particular migration or synchronization task.

Import and export jobs are available under System > Improved Import/Export in the Adobe Commerce Admin. You can create separate jobs for individual processes and configure each one independently.

For example, an Adobe Commerce migration project may use different jobs for:

• migrating the initial product catalog;
• transferring categories;
• importing customers;
• moving historical orders;
• updating inventory before launch;
• synchronizing prices during the transition;
• exporting newly created orders to an ERP after launch.

This approach is particularly useful for staged Adobe Commerce data migration. Instead of trying to move everything in one risky operation, you can divide the migration into smaller processes, test each one, repeat individual transfers when necessary, and run the final updates shortly before switching to the new store.

Jobs can be executed from the Admin, through CLI, or automatically according to their configuration.

Step 2: Configure Scheduling and Migration Automation

The next step is configuring how and when the job should run.

Adobe Commerce already provides scheduled import and export, but its native scheduler is limited to relatively basic recurring patterns. Improved Import & Export uses cron-based scheduling, giving you much more control over when migration and synchronization processes execute.

This matters when Adobe Commerce data migration is not a single event.

Imagine that the source ecommerce platform remains operational during a two-week migration project. Products, stock levels, customers, and orders continue to change while the new Adobe Commerce store is being prepared. Instead of repeatedly creating new files and importing them manually, you can configure migration jobs to run according to a schedule and keep the destination store updated.

The extension also supports CLI execution, job sequencing, and additional automation mechanisms. Import jobs can be arranged into a predefined chain, while exports can be triggered by supported Adobe Commerce events, such as changes to products or orders.

Additional options help control what happens around the migration itself. For example, you can select the indexes that should be refreshed after an import rather than unnecessarily reindexing everything. Imported and exported files can also be archived automatically, making repeated migration runs easier to organize.

The result is a workflow that can continue running after the initial migration. The same jobs used to populate a new Adobe Commerce store can later become permanent ERP, PIM, supplier, marketplace, or inventory synchronization processes.

Step 3: Choose What Adobe Commerce Data You Want to Migrate

Entity coverage is one of the biggest differences between native Adobe Commerce import and Improved Import & Export.

The native importer concentrates on a limited set of entities. Improved Import & Export expands the range considerably, letting you build migration workflows around products, categories, customers, orders, attributes, CMS content, inventory, price rules, reviews, URL rewrites, search data, and other store information.

Supported entities include products, product attributes, categories, customers, orders, CMS pages and blocks, URL rewrites, reviews, newsletters, catalog and cart price rules, gift cards, search terms, widgets, and MSI data.

For Adobe Commerce B2B projects, FireBear also provides a B2B Add-on that extends data transfer to Commerce-specific entities such as companies, shared catalogs, requisition lists, and quotes.

This changes the scope of an Adobe Commerce data migration considerably. Instead of recreating unsupported information manually after products and customers are transferred, you can include far more of the actual store structure and business data in the migration plan.

It is also useful after launch. An order import job, for example, can become part of an integration with an external order management system, while a dedicated category job can synchronize a supplier or PIM taxonomy with Adobe Commerce.

Step 4: Define How Imported Data Should Be Applied

After choosing an entity, you specify how Adobe Commerce should process the incoming records.

Improved Import & Export supports behaviors including Add/Update, Only Add, Only Update, Replace, and Delete, providing more control over what happens to existing data than a simple full migration.

This flexibility is especially valuable when migration happens in several stages.

During the initial catalog transfer, you may need to create products that do not yet exist. Later migration runs may need to update only those products without recreating them. Another job might be used specifically to remove obsolete records from the destination.

Consequently, the same migration configuration can be reused for initial loading, testing, incremental updates, and the final synchronization before launch.

The extension also provides additional control over separators and data structure. This becomes important when supplier, ERP, PIM, or legacy ecommerce files do not follow Adobe Commerce conventions.

Instead of rebuilding every source file manually, you can adapt the job to the data you already have.

Step 5: Connect the Migration Source and Choose a File Format

This is where the difference between the default importer and Improved Import & Export becomes particularly noticeable.

More File Formats for Adobe Commerce Data Migration

Native Adobe Commerce import primarily revolves around CSV. Improved Import & Export supports:

• CSV;
• XML;
• JSON;
• Excel XLSX;
• OpenDocument ODS.

ZIP and TAR archives are also supported for applicable data transfer workflows.

Support for XML is especially important in supplier, PIM, ERP, and marketplace integrations. XML files often arrive in structures that have nothing in common with the Adobe Commerce import format. Improved Import & Export supports XSLT transformations, allowing external XML structures to be transformed into data Adobe Commerce can process instead of requiring the original system to produce a Magento-specific feed.

JSON support opens another common migration and integration path, particularly when data originates from web applications or APIs.

Excel and ODS support can simplify migration projects where catalogs, customer lists, pricing, or other business information is maintained in spreadsheets rather than clean CSV exports.

The important difference is that your Adobe Commerce migration no longer needs to begin by converting every source dataset into a standard Magento CSV manually.

More Adobe Commerce Import Sources

The same principle applies to where the data comes from.

Improved Import & Export supports direct file uploads, FTP/SFTP, Google Sheets, Google Drive, Dropbox, OneDrive, direct URLs, and REST and SOAP APIs.

This creates many migration workflows that the default importer cannot handle directly.

A supplier can update product information in Google Sheets. A PIM can place files on SFTP. An ERP can exchange information through an API. Legacy catalog files can be stored in Google Drive or OneDrive. A remote feed can be retrieved directly from its URL.

Instead of downloading the data, restructuring it, uploading it to Adobe Commerce, and repeating the same process every time something changes, the import job can connect to the source itself.

For Adobe Commerce data migration, this means fewer manual stages between the source and destination systems — and fewer opportunities for outdated files or human errors to enter the process.

Step 6: Map Attributes and Transform External Data

Moving a file is usually the easy part of ecommerce migration. Making two different data models understand each other is much harder.

Suppose a supplier identifies a product with a column called product_code, while Adobe Commerce expects sku. Another platform might call a product name title, while Adobe Commerce expects name.

With attribute mapping, you do not need to rename all of those columns before every import. You can associate external fields with the corresponding Adobe Commerce attributes directly in the job configuration.

The extension also supports attribute value mapping.

Suppose the source system stores a color as rouge, while your Adobe Commerce catalog uses red. You can map the incoming value to the required catalog value automatically. The same mechanism can be used to normalize statuses, option labels, countries, manufacturers, units, and other values during migration.

You can also apply default or static values, populate missing information, clear optional values where required, and use find-and-replace functionality to modify supported text during import.

For common platform migrations, Improved Import & Export provides mapping presets for Magento 1, MagMi, and Shopify. These presets reduce the amount of manual mapping required when moving compatible data from these platforms.

This is one of the most important improvements for Adobe Commerce data migration. Instead of forcing every external system to adopt the Adobe Commerce data structure first, you create a transformation layer between the source and the destination.

Step 7: Map and Migrate Categories

Category structures are another frequent source of problems during ecommerce migrations.

The source platform may organize products according to one taxonomy, while the new Adobe Commerce store uses another. Category names can differ, paths may change, and some categories may need to be merged or moved under different parent categories.

Improved Import & Export provides category mapping, allowing you to associate category paths from the source file with the required category paths in Adobe Commerce.

For example, a legacy store might contain:

Electronics > Computers > Portable Computers

while the new Adobe Commerce catalog uses:

Electronics > Laptops

Instead of editing every product row before migration, the category mapping can direct products to the appropriate destination structure during import.

The extension also supports categories as a dedicated import and export entity, which is especially useful when migrating an entire catalog hierarchy rather than merely assigning categories while products are imported.

That makes category migration a controlled part of the project instead of a manual catalog reconstruction task.

Step 8: Apply Price Rules During Migration

Migration sometimes requires more than copying the original price from one database to another.

Prices may need to be converted for a new market, increased to account for supplier costs, reduced during catalog restructuring, or rounded according to the retailer’s pricing strategy.

Improved Import & Export lets you apply price adjustments during product import. Prices can be increased or decreased using fixed or percentage-based rules, and conditions can determine which products receive the adjustment. Price rounding is also available.

For instance, instead of modifying a supplier price file every morning, you can import the source prices and automatically apply your markup as part of the Adobe Commerce import workflow.

This illustrates a broader advantage of the extension: data can be transformed while it moves.

An Adobe Commerce migration therefore does not have to reproduce the source system exactly. The import workflow can help adapt data to the requirements of the new store at the same time.

Step 9: Rebuild Configurable Products Automatically

Configurable products can make ecommerce migration particularly difficult because transferring their individual SKUs is not enough. The relationships between parent and child products must also be reconstructed correctly.

Improved Import & Export supports the creation of configurable products during import. Parent and child product data can be transferred together with the required configurable attributes so that the extension builds the corresponding relationships in Adobe Commerce.

This is particularly useful when migrating catalogs from another ecommerce platform or importing supplier data that does not reproduce Adobe Commerce configurable product logic exactly.

Rather than manually rebuilding every configurable product after the migration, you can incorporate configurable product creation into the import process itself.

The extension also supports other complex product structures and all major Adobe Commerce/Magento product types, which makes it much more suitable for complete catalog migration than a workflow focused only on simple SKU transfers.

Step 10: Validate, Run, Monitor, and Repeat Data Transfer

Once the source, entity, behavior, mapping, and transformation rules are configured, the job can be saved and executed.

This is where the job-based approach to Adobe Commerce data migration pays off.

You are not creating a disposable import configuration. You are creating a repeatable migration process.

Improved Import & Export provides job history and detailed logs, making it easier to identify what happened during an import or export and investigate errors. Email notifications can also be configured for jobs, including log information.

If something in the migration needs to change, you can modify the job and run it again rather than rebuilding the complete procedure.

For recurring product updates, the extension can also cache imported product files and process changed data during subsequent operations, reducing unnecessary processing. Jobs can be chained into a specified execution order, and processed files can be archived automatically.

This makes the workflow suitable not only for the initial Adobe Commerce data migration, but also for testing, repeated pre-launch updates, final synchronization, and ongoing data exchange after the new store goes live.

Ultimately, Improved Import & Export changes the role of Adobe Commerce import and export. Instead of treating import as a utility for uploading prepared CSV files, you can use it as a configurable data migration and integration layer between Adobe Commerce and your existing ecommerce stack that includes ERP, CRM, PIM, suppliers, cloud storage, spreadsheets, and other external systems.

The native tools remain perfectly suitable for basic transfers. But when migration involves different formats, structures, entities, systems, or recurring updates, Improved Import & Export removes much of the manual preparation that would otherwise have to happen outside Adobe Commerce.

Adobe Commerce Import & Export Guides by Entity

Every Adobe Commerce data migration project is different, and individual entities often have their own file structures, attributes, relationships, and import requirements. The following tutorials provide more detailed instructions for both Adobe Commerce-specific data and common entities shared with Magento Open Source. Use them when you need to go deeper into a particular import or export scenario.

For even more entity-specific tutorials, file-format instructions, integrations, troubleshooting tips, and advanced Adobe Commerce import and export scenarios, refer to the complete FireBear import/export resource hub. Full Magento 2 & Adobe Commerce Import & Export Guide List

Final Words: Make Adobe Commerce Data Migration More Flexible in 2026

Adobe Commerce data migration becomes much easier to manage when you are not limited to rigid CSV structures, a narrow set of entities, or basic scheduling. Native Adobe Commerce import and export tools are useful for straightforward transfers, but more complex migrations often require additional formats, sources, mapping, automation, transformation, and better control over the entire process.

Improved Import & Export expands the standard Adobe Commerce import and export workflow with support for XML, JSON, XLSX, external storage, Google Sheets, FTP/SFTP, APIs, advanced mapping, broader entity coverage, flexible schedules, and detailed job logs. This makes it suitable not only for one-time store migrations, but also for recurring ERP, CRM, PIM, supplier, marketplace, and inventory synchronization.

If your Adobe Commerce data migration involves complex files, unsupported entities, external systems, or recurring data exchange, Improved Import & Export can help turn a fragmented migration process into a reusable and automated workflow.

Need help with Adobe Commerce migration, import, export, or system integration? Contact FireBear to discuss your project and find the right data transfer setup.

Adobe Commerce Data Migration FAQ