On this page
This guide explains when the default tools are enough, what the plugin adds, and how to plan a transfer without treating a spreadsheet as a complete store backup.
When the default nopCommerce tools are enough
nopCommerce already imports products from Excel and exports products to Excel or XML. Its standard tools also support product attributes and multilingual data when configured. If your task is maintaining product rows in an existing store, begin with those built-in tools.
Read the official product import/export guide (opens in a new tab) and catalog settings documentation (opens in a new tab) before choosing a separate plugin.
A more involved transfer raises additional questions: which related records should travel with a product, how should existing records on the target be handled, where should media come from, and how will an administrator review the outcome?
Cartenvo Product Data Exchange organizes those decisions into a package and approval workflow. It uses the core Excel exporter and importer for base product data, then processes additional relationships and resources.
What Cartenvo Product Data Exchange adds
| Transfer concern | Plugin approach |
|---|---|
| Product data with related records | Dedicated worksheets for supported catalog entities and relationships |
| Moving media with the workbook | Portable ZIP packages containing a workbook, manifest, and selected resources |
| Reviewing before changes | Preflight analysis followed by explicit import approval |
| Existing products and related entities | Import policies and reference resolution instead of blindly reusing source database IDs |
| Following processing | Persisted background jobs, progress checkpoints, and logs |
| Checking results | Downloadable job result artifacts and recorded outcomes |
| Malformed spreadsheet values | Header and typed-value validation before catalog mutation |
| Preparing for changes | A pre-import export of affected catalog data when applicable |
These are workflow additions. The comparison does not imply that attributes, localization, or every related field are missing from default nopCommerce import/export.
Which product-related data can be transferred?
Depending on the selected sections and approved policies, a package can carry base products, localized properties, categories, manufacturers, tags, and product relationships.
It also supports worksheets for product attributes and combinations, specification attributes, tier prices, warehouse inventory, pictures, videos, downloads, store mappings, and access-control mappings. Related, cross-sell, associated, and required product relationships have their own transfer paths.
If your catalog depends on custom fields or business rules, a transfer may need additional nopCommerce plugin development.
Why copying database IDs between stores is risky
An ID identifies a record in one database. The same ID in another store may identify a different record, or nothing at all.
For example, a fictional product with SKU DEMO-100 could have product ID 42 on the source store and 310 on the target. Treating 42 as its identity on both stores could connect catalog data to the wrong product.
Source store · source.concept-store.exampleCompact workshop drill
Target store · target.concept-store.exampleCompact workshop drill
Source · SKUDEMO-100
Matched on SKU
Target · SKUDEMO-100
Source · Local product ID42
Not used — IDs differ
Target · Local product ID310
Duplicate SKUs and ambiguous references still need administrator review.
The plugin matches product SKUs and resolves related entities through portable references and import policies. Administrators still need to review duplicate SKUs and ambiguous references; portable matching cannot fix an inconsistent catalog automatically.
The following example is invented to explain the workflow. It is not a client project or a measured migration result.
| Fictional record | Source | Target decision |
|---|---|---|
| Product | SKU DEMO-100, local ID 42 | Match SKU DEMO-100; do not assume ID 42 |
| Category | Workshop Tools | Review category resolution and approved existing-entity policy |
| Manufacturer | Demo Supply | Resolve the reference under the approved policy |
| Tier price | Quantity 10, price 18.50 | Validate the numeric values before import |
| Picture | Selected image resource | Include the resource in the portable package when required |
How a reviewed transfer works
Main path
- 1. ExportSource store job
- 2. UploadPackage on target
- 3. PreflightHeaders, values, references
- 4. ApprovalPolicies confirmed
- 5. Background importApproved file rechecked
- 6. ResultsLogs and result artifacts
From preflight: validation errors
- Errors identify the worksheet, row and field
- Correct the workbook
- Upload the corrected file for a new preflight
Returns to upload. No catalog changes yet.
From import: runtime failure
- Failure after processing has started
- Partial changes are possible
- Operator review of logs, results and the affected-catalog export
Ends at operator review. Not an automatic rollback or resume.
1. Prepare a representative staging sample
Use a small selection that includes a simple product and the more complex records you actually use: attribute combinations, tier prices, localized fields, media, or warehouse inventory.
Take independent database and media backups. Confirm that source and target versions, catalog conventions, permissions, and necessary dependencies are compatible.
2. Export the required sections
Open Catalog → Product Data Exchange → Export Products on the source store. Choose the products and related sections needed for the transfer, then start the export job.
Download the workbook or ZIP artifact. A portable ZIP is useful when the transfer should include selected resources alongside the workbook and manifest. Do not assume every file in the source store is included.
catalog-export.zip
Sample packageproducts.xlsx
Base product data and related worksheets
- Products
- Categories
- Attributes
- Tier prices
- Inventory
- Pictures
manifest.json
Package description and selected sections
media/demo-100.jpg
Selected picture resource
Selected sections and resources only — not a copy of the whole store.
Related data for DEMO-100
- CategoriesWorkshop Tools
- AttributesChuck size · 10 mm
- Tier pricesQty 10 · 18.50
- InventoryMain warehouse · 24
3. Review preflight findings on the target
Open Import Products, upload the package, and inspect the preflight findings before approving changes. Resolve errors and confirm the intended existing-entity and publishing policies.
The approved source file is checked again during execution. A changed package must not be treated as the same approved input.
4. Approve and follow the job
After approval, follow progress and examine Import / Export Logs and the result artifacts. An affected-catalog export is created before eligible changes when applicable.
That export is a useful recovery reference. It is not an automatic rollback or a substitute for a database backup.
5. Verify the storefront and catalog
Inspect product content, categories, media, attributes, prices, stock, and visibility on the target. Check a representative purchase path if the transferred data affects buying behavior.
For a broader platform change, plan the surrounding work separately: redirects, integrations, custom behavior, and operational checks belong in a nopCommerce migration and upgrade plan.
Spreadsheet mistakes to catch before import
The plugin rejects duplicate headers, including differences only in case or surrounding whitespace. It also rejects empty headers between used columns so an ambiguous column layout cannot proceed.
Malformed non-empty numbers, Boolean values, dates, and supported product enum values produce errors identifying the worksheet, row, and field. Tier-price quantity and price must be present. These checks run during preflight and again before import catalog mutations.
| Input example | Recommended correction |
|---|---|
| Two columns named “SKU” and “ sku ” | Keep one unambiguous header |
| Tier price written as “eighteen” | Enter a numeric cell or supported numeric text |
| Decimal text “18,50” | Use a native Excel number or invariant text “18.50” |
| Ambiguous date text “01/02/2026” | Use a native Excel date or an ISO date such as “2026-02-01” |
| Blank tier-price quantity or price | Supply the required numeric value |
Boolean text accepts true, false, 0, and 1. Blank optional fields retain their supported defaults.
Correct formatting avoids interpretation errors; it does not prove that a price or stock value is commercially correct.
Installing the plugin in an existing nopCommerce project
The repository contains plugin source, not a complete nopCommerce application. It targets nopCommerce 4.80 and .NET 9.
Copy the plugin into your existing nopCommerce source tree at:
Plugin folder
src/Plugins/Cartenvo.Plugin.Misc.ProductDataExchange/The project file should be directly inside that folder. Add it to the existing solution if needed, restore dependencies, and build in Release configuration from the nopCommerce repository root:
PowerShell · from the nopCommerce repository root
dotnet restore src/Plugins/Cartenvo.Plugin.Misc.ProductDataExchange/Cartenvo.Plugin.Misc.ProductDataExchange.csproj
dotnet build src/Plugins/Cartenvo.Plugin.Misc.ProductDataExchange/Cartenvo.Plugin.Misc.ProductDataExchange.csproj --configuration ReleaseThe project directs output to the web host’s plugin folder. Reload the plugin list in administration and install Cartenvo Product Data Exchange using the normal local plugin workflow.
Limitations to include in your transfer plan
Frequently asked questions
Does this replace the default nopCommerce importer?
No. It uses nopCommerce’s core Excel import/export services for base products and adds a coordinated package, relationship, and approval workflow.
Can it migrate an entire nopCommerce store?
No. Its scope is standard product and related catalog data. Orders, customer accounts, discounts, and custom project fields are outside that scope.
Is the pre-import export a full backup?
No. It exports affected catalog data when applicable. It does not provide an exact database restore or automatic rollback.
Do users need to install nopCommerce separately?
Yes. The plugin source must be built within an existing compatible nopCommerce source installation. The repository does not include the complete application.
Can the plugin be extended for custom catalog rules?
An extension may be possible, but custom fields, matching rules, and integrations require separate design and validation. They should not be assumed to work through the standard package format.
Plan your next catalog transfer
Start by choosing whether the default tools meet your task, listing the related data you need, and testing a representative sample on staging.
For a transfer involving custom catalog logic or integrations, contact Cartenvo or email contact@cartenvo.com. Our custom nopCommerce development service can help define the work around the plugin.