Migration requirements often sit between two extremes. The default supported migration may already cover the core data, yet the project can still need tighter control over which records move, how selected values change, where supported values are routed, or whether an eligible database location should receive them. Next-Cart Add-ons exist for those bounded problems.
The useful question is not whether a requirement sounds unusual. It is which layer of the migration result must change. A precise answer keeps a supported enhancement from being escalated unnecessarily to Custom Service, while also preventing an Add-on from being stretched into work that depends on unsupported data, bespoke logic, or target-side application behavior.
Start With the Type of Change
Four questions separate the Standard Add-ons:
- Which records should remain in the migration scope? This is a Data Filter question.
- How should a supported value change before it is routed onward? This is a Data Transformationquestion.
- Which compatible target field should receive a supported source or transformed value? This is an Advanced Data Mapping question.
- Does supported data need a database-level destination that is supported for both the selected Source setup and Target Platform? This is an Advanced Database Mapping question.
These questions follow the processing sequence deliberately. Filtering establishes the active records. Transformation changes supported values on that active dataset. Advanced Data Mapping routes supported values to compatible target fields without changing them during mapping. Advanced Database Mapping then handles eligible database tables, fields, or columns when both sides of the migration support the Add-on and the specific database locations are compatible.
That distinction is more useful than treating all four capabilities as generic customization. Each Add-on changes a different part of the result.
Four Standard Add-ons, Four Different Responsibilities
| Standard Add-on | Primary role | Strong-fit signal | Position in the processing sequence | Fixed price |
|---|---|---|---|---|
| Data Filter | Select which records continue by applying supported field-based conditions to a data type. | Only a defined subset of otherwise eligible records should migrate. | First. It establishes the active record population for later stages. | $50 |
| Data Transformation | Change supported values on the active dataset through supported expressions. | A source value must be normalized, recalculated, reformatted, prefixed, or otherwise changed before it is routed onward. | Second. Later mapping stages receive the transformed value where the same field participates. | $50 |
| Advanced Data Mapping | Route a supported source or transformed value to a compatible target field without changing the value during mapping. | The value is acceptable after any required transformation, but it belongs in a different supported target field. | Third. It establishes supported field destinations. | $50 |
| Advanced Database Mapping | Route supported data through eligible database tables, fields, or columns to compatible target locations. | The requirement depends on database-level representation, both sides of the migration support the Add-on, and the specific database locations are compatible. | Fourth. It operates only after the earlier applicable stages have established the active dataset and values. | $100 |
The four capabilities can be purchased independently. A project does not need to use the complete sequence merely because several Add-ons exist. The sequence matters only for the Add-ons that are actually part of the migration.
Data Filter: control record participation
Data Filter is appropriate when the business decision is which records belong in the result.
A useful filtering requirement names the data type, the supported source field, the condition, and the intended inclusion or exclusion outcome. Examples include migrating only enabled Products, excluding test Customers, or limiting Orders to a defined date range when the required fields and operators are available.
Filtering does not change the meaning of a retained value and does not choose its destination. A record excluded by Data Filter does not continue into later Add-on stages for that filtered data type. Other selected data types remain in the active dataset unless their own filter rules change them.
Entity Points remain a separate capacity concept. An Entity Points quantity helps size the purchased migration, but it does not identify which individual records should migrate. Data Filter makes that scope decision when supported conditions can express it.
Standalone use cases for Data Filter
Migrate only active catalog records. A merchant is retiring disabled Products and wants only Products whose supported status field indicates they are active. Data Filter fits because the decision concerns record participation. Validation should compare included and excluded samples against the agreed condition.
Limit historical Orders to an agreed period. A business needs only Orders created after a defined date. When the relevant date field and comparison are supported, Data Filter can establish that population before transformation or mapping begins. Validation should include boundary dates and known exception Orders.
Data Transformation: change the value before routing
Data Transformation is appropriate when the value itself must change. The requirement should define the input, the transformation rule, the expected output, and important edge cases.
Examples include adding a prefix to a Product identifier, applying an arithmetic expression to a supported price value, normalizing a text value, or producing another supported target-compatible result. The transformation changes the value on the active dataset; it does not decide which target field or database column should ultimately receive that value.
Its position before both mapping stages is important. When a field is transformed and then mapped, the mapping stage receives the transformed value. This makes the intended data flow easier to reason about: first determine what the value should become, then determine where that resulting value belongs.
Standalone use cases for Data Transformation
Apply a price rule. A project needs a supported Product Regular Price to increase by 12%. A value of 80.00 becomes 89.60 under the agreed expression. Validation should include ordinary prices, decimal values, and boundary cases relevant to the business rule.
Standardize a Product model before destination mapping. A business wants TSHIRT-001 to become WEB-TSHIRT-001. Data Transformation can establish the changed value first. If the value must later become a target SKU, Advanced Data Mapping can route the transformed value without recreating the transformation rule.
Advanced Data Mapping: keep the value, change the field destination
Advanced Data Mapping is appropriate when a supported value is already correct after any required transformation but needs a different compatible target field.
A strong mapping requirement identifies the source field, target field, business meaning, and value compatibility. The target field must be able to represent the complete value it receives. Mapping does not recreate application behavior merely because a value reaches a field that an app, theme, extension, or integration may use.
Tax data is outside Standard Advanced Data Mapping scope. A requirement that depends on unsupported fields, relationships, or target behavior should be assessed separately rather than approximated through a similarly named field.
Standalone use cases for Advanced Data Mapping
Route Product Model to SKU. Assume Product Model has already been normalized to WEB-TSHIRT-001. When the supported source field and target SKU field are compatible, Advanced Data Mapping can route that value to SKU without changing it during mapping. Validation should confirm both the stored value and the business process that consumes the target SKU.
Route a supported Customer value to a different contact field. If two platforms organize a supported Customer contact value differently, Advanced Data Mapping can route the source value to a compatible target field when the semantic meaning and value representation remain valid.
Advanced Database Mapping: confirm both sides and the specific mapping
Advanced Database Mapping is for supported database-level routing. It is not determined by a broad platform architecture label.
Before treating the Add-on as a Standard capability, confirm all four conditions:
- the selected Source setup must support Advanced Database Mapping;
- the selected Target Platform must also support Advanced Database Mapping;
- the required data type, table, field, or column must be available through the supported schema for that migration context;
- the destination must be semantically appropriate and able to represent the complete Value Type it receives.
The exact Source selection matters because related platform selections can expose different database-mapping capabilities. A File Upload profile and an API profile from the same platform family should not inherit eligibility from each other. Likewise, a platform that is supported as a Source is not automatically supported as a Target.
Some eligible Source selections use structured input rather than a native published database schema. In those cases, eligibility follows the fields and structures exposed by the active migration rather than a fabricated platform database table. The absence of a published native table should therefore not be replaced with guessed schema information.
Tax data is outside Standard Advanced Database Mapping scope. Database storage also does not recreate target-side behavior. A value can be written to a supported location without automatically becoming usable by an admin screen, storefront theme, extension, app, search index, integration, or business workflow.
Standalone use cases for Advanced Database Mapping
Preserve an eligible legacy warehouse value. In an eligible Source-to-Target path, a supported source database value such as WH-A-03 may need to be routed to an approved compatible target database column. Advanced Database Mapping can fit when both sides of the migration support the Add-on and the specific database locations are compatible. Validation should confirm the stored value and the downstream process that is expected to consume it.
Route a supported custom database value without recreating custom logic. A custom column can be a valid mapping source or destination when it is exposed and compatible within Standard scope. The presence of the word custom does not automatically require Custom Service. The question is whether the exact platform roles, schema locations, value representation, and required behavior remain supported.
Why the Fixed Processing Order Matters
The fixed Next-Cart Add-on sequence is:
Data Filter -> Data Transformation -> Advanced Data Mapping -> Advanced Database Mapping
The order creates a predictable data flow:
- Data Filter establishes the records that remain active.
- Data Transformation changes supported values on those records.
- Advanced Data Mapping routes supported source or transformed values to compatible target fields.
- Advanced Database Mapping performs eligible database-level routing after the earlier applicable stages.
The safest way to design a multi-Add-on requirement is to describe the intended final Target Store result, then trace the data forward through those four responsibilities. This prevents a filtering condition from being confused with a transformation rule, a transformation from being embedded in field routing, or a database-level request from being approved before role and schema eligibility are known.
A Combined Add-on Example
Consider an OpenCart-to-Adobe Commerce migration in which Advanced Database Mapping is supported for both sides and the required Product database locations and Value Types are compatible.
One source Product contains:
- Status:
Enabled - Quantity:
25 - Model:
TSHIRT-001 - Location:
WH-A-03
For this example, the business has explicitly defined a sellable Product as one whose source Status is Enabled and whose source Quantity is not 0. That project-specific definition is not a universal inventory rule. The business also wants to standardize the Product model for web use, use the standardized model as the target SKU, and preserve the warehouse location in an approved Adobe Commerce database location.
Stage 1: Data Filter
Apply the agreed Product conditions, such as Status equals Enabled and Quantity does not equal 0. The Product remains in the active dataset; disabled or zero-stock Products do not continue through the remaining Product Add-on stages.
Stage 2: Data Transformation
Transform Product Model by adding the WEB- prefix:
TSHIRT-001 -> WEB-TSHIRT-001
The active Product now carries the standardized Model value that later mapping can route.
Stage 3: Advanced Data Mapping
Route the transformed Product Model to the compatible target SKU field. The intended target SKU becomes:
WEB-TSHIRT-001
The mapping stage does not change the value again. It changes the supported destination.
Stage 4: Advanced Database Mapping
Route the supported source location value to the approved compatible Adobe Commerce database destination, for example an accepted column used to retain the legacy warehouse location. The value WH-A-03 remains unchanged during this mapping operation.
The database step is valid only because the selected OpenCart Source setup and Adobe Commerce Target Platform support Advanced Database Mapping and the requested database locations are compatible. The platform names alone are not enough; the requested field or column still has to exist in the supported schema and accept the value correctly.
The combined result illustrates the division of responsibility: filtering chooses the Products, transformation establishes the standardized value, field mapping routes that value to SKU, and database mapping preserves a separate eligible database-level value. Validation should confirm each layer independently and then confirm that the resulting Target Store behavior is usable.
Distinguish Standard, Tailored, and Custom Add-on Work
Function and scope tier are separate decisions.
| Add-on tier | Meaning | Commercial treatment |
|---|---|---|
| Standard Add-on | A pre-built fixed-scope capability used without modification. | Fixed catalog price. |
| Tailored Add-on | A Standard Add-on function that needs project-specific tuning, modification, or expanded scope. | Reviewed and quoted through Custom Service. |
| Custom Add-on | Bespoke Add-on functionality outside the Standard catalog. | Reviewed and quoted through Custom Service. |
Several Standard Add-ons can work together without making the migration a Custom Service project. A custom field or database column also does not automatically trigger Custom Service. The supported Standard boundary should be tested first.
Custom Service becomes relevant when the required result exceeds those boundaries, for example unsupported extraction, custom application logic, bespoke relationships, non-standard APIs, unsupported schema handling, or project-specific Add-on behavior that the Standard capability cannot express.
Separate Stored Data From Target Behavior
A successful Add-on result proves a data outcome only to the extent that the agreed validation demonstrates it.
A mapped identifier may exist but not be used by an ERP connector. A database value may be stored but ignored by the target extension that was expected to consume it. A transformed status may be syntactically valid but operationally wrong for the target workflow. A correctly filtered catalog may still exclude records required for legal, SEO, or customer-service reasons.
For that reason, every Add-on requirement should have an acceptance statement that covers both the migrated value and the business consequence that matters. Storage, visibility, and behavior are separate evidence questions.
Distinguish Data-Type Scope From Record Filtering
Data Filter controls records inside a data type that is already part of the migration. It does not decide whether the entire data type belongs in scope. Whole-data-type inclusion or exclusion is a separate configuration decision.
A Standard Data Filter requirement is reliable only when the active migration exposes the field and operator needed to express the approved business predicate exactly. This makes apparently simple requests worth qualifying before they are converted into filter rules.
| Requirement | Evidence needed before treating it as a Standard Data Filter rule |
|---|---|
| Only active Products | A Product field represents the exact active or saleable state intended by the project. |
| Only recent Orders | The relevant Order creation time and a compatible date comparison are available. |
| Products from selected Categories | The available condition represents the required Product-to-Category membership. |
| Customers who placed at least one Order | The available condition represents the required Customer-to-Order relationship or an approved equivalent. |
| Products that are in stock | The project defines what in stock means and the available fields can express that exact stock, quantity, or location-aware rule. |
| Valid or unused Coupons | The business definition of valid and unused is explicit and every necessary status, date, or usage condition can be represented. |
| Blog Posts published after a date | The available field represents actual publication time when publication time is the requirement. |
A similar-looking field is not evidence of support. For example, creation or update time should not be substituted for publication time, and a general Product status should not be used as a proxy for Category membership or stock meaning. When the required predicate cannot be represented safely, the requirement needs a revised scope or Custom Service review rather than an approximate filter.
Understand Pricing, Later Additions, and Duration
Standard Add-on prices are fixed at $50 for Data Filter, $50 for Data Transformation, $50 for Advanced Data Mapping, and $100 for Advanced Database Mapping.
An Add-on can be part of the initial purchased migration or added later when the migration remains eligible. A later addition is integrated into the same fixed Source-to-Target migration path and uses the applicable difference-only upgrade principle rather than creating a separate migration.
An upgrade does not change the expiration of the active service period. If an expired migration is extended, the extension renews access separately and carries forward the applicable retained package, including eligible Add-ons already integrated into the migration. Successful payment for an extension establishes the next 12-month access period from the extension settlement time.
Pricing should therefore be read in two layers: the Add-on price describes the bounded capability, while the Migration Service, Entity Points Plan, and any accepted Custom Service work determine the wider project total.
Use a Requirement Test Before Selecting an Add-on
A practical Add-on decision can be reduced to five checks:
| Question | Decision value |
|---|---|
| Which records should participate? | Whether Data Filter is needed. |
| Must a supported value change before routing? | Whether Data Transformation is needed. |
| Is the resulting value correct but intended for a different compatible target field? | Whether Advanced Data Mappingis needed. |
| Does the requirement need database-level routing, and do the selected Source setup, Target Platform, and specific database locations support it? | Whether Advanced Database Mapping should be evaluated. |
| Does any required behavior exceed the supported Standard capability? | Whether Tailored or Custom Add-on work through Custom Serviceshould be assessed. |
Words such as include, exclude, only, or condition often signal filtering. Calculate, normalize, prepend, append, convert, or restructure often signal transformation. Map, route, place, or destination often signal field mapping. References to database tables, columns, platform-specific fields, or custom fieldsmay signal Advanced Database Mapping, but only after exact eligibility and compatibility are established.
These are diagnostic signals, not automatic approvals. The active migration still determines which fields, operations, mappings, and database destinations are available.
Conclusion
Next-Cart Add-ons are most useful when each requirement is assigned to the layer it actually changes. Data Filter controls record participation. Data Transformation changes supported values. Advanced Data Mapping routes supported values to compatible target fields. Advanced Database Mapping handles eligible database-level routing only after both sides of the migration and the specific database locations are confirmed as compatible.
Their fixed order is Data Filter -> Data Transformation -> Advanced Data Mapping -> Advanced Database Mapping. That sequence makes multi-Add-on requirements easier to reason about because each stage receives the active dataset and values established by the applicable stages before it. When the requirement exceeds those bounded capabilities, Tailored or Custom Add-on work belongs in Custom Service rather than being forced into a Standard Add-on.
Common Questions
Can several Standard Add-ons be used in one migration?
Yes. Several Standard Add-ons can address different parts of one supported requirement. The project should still define each Add-on’s responsibility and validate the combined result in the fixed processing order.
What is the Add-on processing sequence?
The sequence is Data Filter, Data Transformation, Advanced Data Mapping, then Advanced Database Mapping. Transformation therefore occurs before the mapping stages.
Is Advanced Database Mapping determined by whether both platforms are open-source?
No. Availability depends on the selected Source setup, the Target Platform, and compatibility of the specific database locations involved in the mapping. A broad architecture label is not enough.
Can a File Upload Source qualify for Advanced Database Mapping?
Potentially. Some structured Source selections can be used with Advanced Database Mapping even when they do not have a published native platform database schema. The required source structure must be available, the Target Platform must support Advanced Database Mapping, and the specific destination must be compatible.
What is the difference between Data Transformation and Advanced Data Mapping?
Data Transformation changes the supported value itself. Advanced Data Mapping routes a supported source or transformed value to a compatible target field without changing that value during the mapping operation.
Does a custom field or database column automatically require Custom Service?
No. First test the requirement against supported Advanced Data Mapping or Advanced Database Mapping scope. Custom Service is appropriate when the required handling exceeds the supported Standard capability or depends on bespoke logic or unsupported structures.
Do Advanced Data Mapping and Advanced Database Mapping support Tax data?
No. Tax data is outside the Standard scope of both mapping Add-ons.
Does storing a mapped value guarantee that an app, theme, or integration will use it?
No. Storage and business behavior are separate. The consuming target behavior must be validated independently.
Does adding an Add-on later extend the migration duration?
No. A later Add-on purchase changes the existing migration package but does not change the expiration of the active service period. Extension is the separate renewal mechanism for an expired migration.
Can Data Filter select active Products, recent Orders, or Blog Posts after a date?
Yes only when the active migration exposes the exact field and operator needed to express the approved condition. An active-Product rule must use the field that actually represents the intended active state. A recent-Order rule requires the relevant Order time field. A publication-date rule requires a real publication-time field when publication time is the business requirement; creation or update time should not be substituted merely because it is available.
Can Data Filter select Products by Category or Customers who placed an Order?
Only when the available filtering model can represent the required relationship. Product-to-Category membership and Customer-to-Order history are relationship conditions, not simple label matches. If the active fields and operators cannot express the relationship accurately, do not approximate it with an unrelated field; the requirement needs a different supported scope or Custom review.
Can Data Filter identify in-stock Products or valid and unused Coupons?
Only after the business meaning is defined precisely and the available fields can express it. In stock may depend on quantity, status, location, or another inventory rule. A Coupon may require status, date, and usage conditions together to qualify as valid and unused. A similar-looking field is not enough evidence for a reliable filter.