Add-ons

Migration requirements often sit between two extremes. The default supported migration can be structurally appropriate, yet the business may still need tighter control over which records move, where particular values land, or how selected values should be changed before they reach the Target Store. That is the role of Add-ons within Next-Cart Migration Services.

The important decision is not simply whether an Add-on sounds relevant. Each Add-on solves a different kind of data-handling problem, and several Add-ons can work together when one migration requirement involves multiple stages. Understanding those distinctions helps keep supported enhancements separate from broader Custom Service work.

Add-ons Solve Bounded Data-Handling Problems

Add-ons extend supported migration behavior without changing the fundamental migration path. A useful Add-on requirement starts with the business result that must be produced and then identifies the specific operation needed to reach it.

Four questions separate the Standard Add-ons clearly:

• Which records should continue through the migration? This is a Data Filter question.
• Which compatible target field should receive a supported source field? This is an Advanced Data Mapping question.
• Does the requirement need supported field or database-column mapping when both the Source Platform and Target Platform are open-source? This is an Advanced Database Mapping question.
• How should a selected target field value be changed during migration? This is a Data Transformation question.

These functions are related, but they are not interchangeable. Filtering changes record scope. Mapping changes destination. Database mapping can operate at the underlying database layer within its supported boundary. Transformation changes the selected target value.

Four Standard Add-ons, Four Different Decisions

The four Standard Add-ons are best understood by the layer of the migration result they control. They are not four versions of the same feature. One controls which records participate, two control where supported values are represented, and one controls what the resulting target value becomes.

Standard Add-on	Primary role	Strong-fit signal	Role in a combined workflow	Fixed price
Data Filter	Choose which records migrate by applying supported field-based conditions to a data type.	The business needs only a defined subset of otherwise eligible records.	Runs first and establishes the record population seen by every later Add-on.	$50
Advanced Data Mapping	Remap a supported source field to a compatible target field without changing the value as part of the mapping operation.	The source value is already correct, but it belongs in a different supported target field.	Runs after filtering and establishes supported field destinations before database-level mapping.	$50
Advanced Database Mapping	Map supported fields and underlying database columns to compatible target fields or columns, including eligible platform-specific and custom fields.	The requirement depends on database-level representation rather than only the supported field layer.	Runs after Advanced Data Mapping and can establish the value or destination that Data Transformation receives next. Available only when both platforms are open-source.	$100
Data Transformation	Transform selected target field values during migration.	The final target value itself must be recalculated, normalized, reformatted, or otherwise changed by a supported rule.	Runs last and works with the target value available after the mapping stages.	$50

The table is useful because the same business requirement can contain several of these signals at once. A request to “migrate only these Products, place one source value in a different field, use a custom database value for Price, then apply a margin” is not one vague customization problem. It is four distinct operations that can be evaluated independently and then combined in the required processing order.

Data Filter: control the record population

Data Filter is the right starting point when the business can describe which records belong in the migration result through supported field-based conditions.

Typical questions include:

• Should only active Products be included?
• Should Orders be limited to a defined business period or status condition?
• Should only Customers that meet an agreed field condition continue?
• Should a content data type be narrowed to the records relevant to the new Store?

The important boundary is that Data Filter changes record participation, not the record’s field destination or value. A Product excluded by the filter never reaches later Add-on processing for that migration scope. A Product that passes the filter continues with its supported data available for the mapping and transformation stages that follow.

This makes Data Filter especially important in combined requirements. If a later mapping or transformation rule should affect only part of a catalog, filtering establishes that population first rather than asking a later Add-on to distinguish records it was not designed to select.

Entity Points remain a separate capacity concept. Products, Customers, Orders, and Blog Posts can consume Entity Points according to their counted weights, but an Entity Points quantity does not identify which individual records should migrate. Data Filter addresses that selection decision.

Standalone use cases for Data Filter

Use case: migrate only enabled Products. A merchant is retiring discontinued and disabled catalog records and wants the migration scope to contain only Products whose supported status field indicates they are enabled. Data Filter is the relevant control because the business decision concerns which Product records participate, not where their values are mapped or how those values are changed. The exact condition remains subject to the supported fields and operators for the selected migration path.

Use case: limit Orders to a defined business period. A business may need only Orders created after an agreed date for the migration project, while older historical Orders remain outside the intended scope. When the required date field and comparison are supported, Data Filter can establish that record population before any later mapping or transformation rules are evaluated. The filtering decision does not change the meaning of the selected Orders; it determines which records continue.

Advanced Data Mapping: keep the value, change the supported destination

Advanced Data Mapping fits when the source value is acceptable but its supported target destination is not.

The mental model is direct reassignment:

supported source field -> compatible target field

For example, if the selected migration path supports both Product Short Description and Description, a requirement may call for the source Short Description value to become the target Description. The value itself does not need to be recalculated. The migration needs a different supported destination.

That distinction is useful in practice:

• “Put this supported source value in that compatible target field” points toward Advanced Data Mapping.
• “Change this value before it reaches the Target Store” points toward Data Transformation.
• “The value exists in an underlying database column that requires database-level handling” may point toward Advanced Database Mapping when the platform path is eligible.

In a combined workflow, Advanced Data Mapping receives only the records that passed Data Filter. It establishes supported field destinations before Advanced Database Mapping and Data Transformation run. When later stages affect a related or identical target destination, the sequence determines which value is available for subsequent processing.

Advanced Data Mapping still has boundaries. The source field and target field must be supported and compatible, and Tax data is outside the Standard mapping scope. A destination change also does not guarantee that target-side applications, themes, extensions, or business logic will use the mapped value in a particular way.

Standalone use cases for Advanced Data Mapping

Use case: use Product Short Description as the target Description. The source text is already correct, but the Target Store needs that supported value in a different compatible field. Advanced Data Mapping fits because the requirement is a direct destination change: Short Description -> Description. The mapping operation preserves the value rather than rewriting it.

Use case: reassign a supported Customer contact value. A migration may contain a supported Customer contact field whose value needs to land in another compatible target contact field because the two platforms organize customer information differently. When both fields are supported and the target can represent the source value correctly, Advanced Data Mapping can make that reassignment without turning a field-destination problem into a transformation or Custom Service requirement.

Advanced Database Mapping: work with eligible database-level representation

Advanced Database Mapping becomes relevant when a requirement cannot be described only as one supported application field moving to another supported field. It extends supported mapping to eligible fields and underlying database columns, including platform-specific and custom fields that remain within the Standard capability.

Its availability is intentionally narrower because database-level handling depends on the architecture on both sides of the migration. Both the Source Platform and the Target Platform must be open-source. If either platform is non-open-source, Advanced Database Mapping is not available.

That architecture condition answers only the first eligibility question. A qualifying platform path does not automatically make every field or column mappable. The actual requirement must still be checked for:

• supported source field or database-column participation;
• a compatible target field or column;
• sufficient value type compatibility;
• supported relationships and data meaning;
• exclusion of Tax data from the Standard mapping scope.

The Add-on is therefore most useful when the business can clearly identify the database-level value that must survive, the compatible place it should occupy in the Target Store, and the evidence that will prove the mapped result is useful.

In the processing sequence, Advanced Database Mapping runs after Advanced Data Mapping and before Data Transformation. This position matters when database-level mapping establishes a value that must then be recalculated or reformatted. Data Transformation receives the result available after both mapping stages, so the database mapping can become the direct input to the final value-changing rule.

Database mapping also remains separate from target-side implementation. Successfully storing a value in a compatible target field or column does not prove that a theme, extension, application workflow, tax rule, or storefront feature will interpret or display that value as intended. Those outcomes require their own validation.

Standalone use cases for Advanced Database Mapping

Use case: use a supported custom numeric Product column as a target price value. On an eligible Open-Source-to-Open-Source path, a merchant may have a supported custom database column such as regional_base_price that needs to populate a compatible target price field or column. Advanced Database Mapping is relevant because the source of the value sits at the database layer. The architecture gate alone is not enough: the exact source column, target destination, Value Type compatibility, and Standard scope must still be confirmed.

Use case: preserve a supported platform-specific database value. An Open-Source source platform may store an important Product value in a platform-specific database column rather than in the standard field layer. If the selected Open-Source Target Platform has a compatible supported destination and the requirement remains a direct value-preserving mapping, Advanced Database Mapping can carry that value to the intended target field or column. This does not imply that every target theme, app, extension, or workflow will automatically use the stored value.

Data Transformation: change the final target value

Data Transformation fits when the destination is known but the value that should exist there must change.

Common patterns include:

• applying an arithmetic rule to a numeric value;
• adding, removing, or restructuring text through a supported expression;
• normalizing values into an agreed target representation;
• calculating a final value from data established by an earlier mapping stage.

The strongest distinction is simple: mapping answers where should this value go? Transformation answers what should the resulting value become?

Because Data Transformation runs last, it works with the target value available after Advanced Data Mapping and, where eligible, Advanced Database Mapping. This makes it particularly useful as the final stage of a compound requirement. If database-level mapping establishes the target Price, for example, a subsequent transformation can calculate the final Price from that mapped value rather than from an earlier source-field assumption.

Data Transformation does not choose which records participate and does not decide which target field or column should receive a source value. Those decisions belong to the earlier stages. A well-defined transformation therefore starts with a known target field, a known input value after mapping, and a clear supported rule for producing the intended output.

Standalone use cases for Data Transformation

Use case: increase the resulting target price by 12 percent. A merchant may want the target Regular Price to be 12 percent higher than the value established by the preceding mapping stage. Data Transformation fits because the destination is already known and the resulting value must change. A supported calculation such as Regular Price x 1.12 is therefore a transformation rather than a mapping decision.

Use case: normalize a target text value. A source and target may represent the same business value with different text conventions. When a supported transformation rule can normalize the final target text into the required representation, Data Transformation is the relevant Add-on. The rule operates on the target value available after applicable mapping stages; it does not select records or decide which target field should receive the source value.

Why the Processing Sequence Matters

When several Add-ons are used together, they are processed in a fixed order:

Data Filter -> Advanced Data Mapping -> Advanced Database Mapping -> Data Transformation

The sequence creates a useful way to reason about compound migration requirements:

1. Selection: Which records are allowed to continue?
2. Field destination: Where should supported source fields be represented?
3. Database-level destination: Does an eligible open-source-to-open-source migration need supported field or database-column mapping beyond the standard field layer?
4. Final value: What should the resulting target value become after mapping is complete?

Each applicable stage works with the result established by the stages before it. That does not mean every migration needs all four Add-ons, or that every Add-on must affect the same field. It means the requirement should be designed as one ordered data journey rather than as unrelated rules configured in isolation.

Common Add-on combinations

Many real requirements need only two or three stages. Recognizing the pattern makes it easier to evaluate suitability before deciding that custom work is necessary.

Business requirement pattern	Likely Add-on combination	Why the combination fits
Migrate only a defined subset of records, then modify one of their target values.	Data Filter + Data Transformation	Filtering defines who participates; transformation changes the required value only for those records.
Send a supported source field to a different compatible target field, then change the resulting value.	Advanced Data Mapping + Data Transformation	Mapping establishes the destination; transformation operates on the value available there afterward.
Use an eligible database-level value as a target value, then apply a calculation or normalization rule.	Advanced Database Mapping + Data Transformation	Database mapping establishes the target value; transformation produces the final value. Both platforms must be open-source for the database-mapping stage.
Limit the records, redirect supported fields, and then modify the resulting target values.	Data Filter + Advanced Data Mapping + Data Transformation	The workflow combines record scope, destination control, and final value change without requiring database-level mapping.
Limit the records, apply supported field mapping, use eligible database-level mapping, then transform the final result.	All four Standard Add-ons	Each stage solves a different part of one compound requirement and feeds the next relevant stage.

The presence of several stages does not make the project a Custom Service case by itself. If every operation remains inside the supported Standard scope for its Add-on, the combined requirement can still be addressed with Standard Add-ons. Custom handling becomes relevant when one of those operations itself needs modification, unsupported data interpretation, bespoke logic, or another capability outside the Standard boundaries.

A practical planning method is to work backward from the intended Target Store result. Identify the final value or representation first, then determine whether it needs transformation, database-level mapping, field mapping, record filtering, or some combination of those controls.

A Combined Add-on Use Case

Consider an OpenCart-to-WooCommerce migration in which the required Product fields are supported and the selected custom database column passes the applicable mapping and compatibility checks. Both are open-source platforms, so the migration path can be evaluated for Advanced Database Mapping.

The merchant wants to achieve four connected outcomes:

• migrate only Products that are enabled and still have stock;
• use the source Short Description as the target Description;
• use a supported custom numeric Product database column named regional_base_price as the target Regular Price;
• increase that resulting Regular Price by 12 percent during migration.

No single Add-on solves the complete requirement.

Stage 1: select the Product records

Data Filter applies the agreed Product conditions, such as an enabled status and a stock quantity above zero. Products that do not satisfy the conditions do not continue into the remaining Add-on processing for this migration scope.

The filter solves only the selection problem. It does not decide how descriptions or prices are represented on the Target Store.

Stage 2: redirect the supported description field

Advanced Data Mapping maps the supported source Short Description field to the compatible target Description field.

This changes the destination of the supported value while keeping the mapping operation distinct from any later value modification.

Stage 3: establish the price from a database-level source

Advanced Database Mapping maps the supported custom numeric regional_base_price database value to the compatible target Regular Price destination.

This stage is possible for the example only because both sides of the migration path are open-source platforms and the specific field or column requirement is assumed to pass the Standard Add-on eligibility checks. A custom column should not be assumed to qualify merely because Advanced Database Mapping exists.

Stage 4: calculate the final target price

Data Transformation then applies the required calculation to Regular Price, for example:

Regular Price x 1.12

Because Data Transformation runs after both mapping stages, it operates on the Regular Priceestablished through Advanced Database Mapping rather than on an unrelated earlier price value.

The final result demonstrates why Add-ons should be evaluated as a coordinated processing sequence. Data Filter defines the participating Products, the mapping stages establish where the relevant information is represented, and Data Transformation produces the final calculated price.

The migrated result still requires validation. The example demonstrates data handling, not a guarantee that every downstream pricing rule, theme, extension, tax behavior, or storefront presentation is automatically configured by the migration.

How Add-ons Interact When They Touch the Same Data

Combined Add-ons can interact in several different ways. Understanding the pattern matters more than simply counting how many Add-ons are present.

Interaction pattern	What happens conceptually	Reader implication
Same records, different fields	Data Filter establishes the participating records, while separate mapping or transformation rules affect different fields within those records.	The Add-ons are coordinated by record scope even when they do not touch the same destination.
Different mapping stages, same destination	Advanced Data Mapping and Advanced Database Mapping can both contribute to how a target destination is established. The later applicable mapping stage determines the value available to subsequent processing.	Overlapping mapping rules should express one deliberate final-data strategy rather than independent intentions.
Mapping followed by transformation	A mapping stage establishes the target value or destination, then Data Transformation changes the value that exists after mapping.	Transformation rules should be designed against the mapped result, not against an earlier source value that is no longer the relevant input.
Filtering plus downstream processing	Data Filter excludes records from the participating migration population before any mapping or transformation takes place.	Downstream Add-ons should be evaluated against the filtered population that will actually reach them.

This interaction model makes compound requirements easier to review. A merchant can separate a business request into record scope, destination, database-level representation, and final-value logic, then check whether those pieces reinforce one another or create competing assumptions.

The most sensitive case is when multiple mapping rules affect the same target field or column. In that situation, the processing order determines the value available to Data Transformation. The safest design starts from the intended final Target Store value and traces backward through the sequence, confirming which stage should establish each intermediate result.

That backward check is also useful when the Add-ons affect different fields. It reveals unnecessary rules, destinations that do not support the source meaning, transformations that expect the wrong input, or records that should have been excluded before later processing began.

Compatibility Is More Than Matching Field Names

A source field and target field can have similar labels without being compatible. Mapping decisions should consider whether the Target Platform can represent the source value correctly.

For the mapping Add-ons, the target field or column must have sufficient value type capacity for the source value. A numeric source value can often be represented in a text destination, while arbitrary text cannot safely be treated as a number merely because a few sample values happen to look numeric. When compatibility is uncertain, it should be validated rather than assumed.

The mapping Add-ons also have functional boundaries. Tax data is outside the supported Advanced Data Mapping and Advanced Database Mapping scope. Requirements involving unsupported data types, fields, columns, relationships, scripts, or application behavior may need Tailored Add-on, Custom Add-on, or broader Custom Service review.

Standard, Tailored, and Custom Add-ons

The function needed and the amount of customization needed are separate decisions.

Add-on tier	Meaning	Pricing treatment
Standard Add-on	A pre-built Add-on used within its supported fixed scope.	Fixed catalog price.
Tailored Add-on	A Standard Add-on function that needs tuning, modification, or expanded scope beyond the Standard capability.	Reviewed and quoted through Custom Service.
Custom Add-on	Bespoke Add-on functionality outside the functional scope of the Standard Add-on catalog.	Reviewed and quoted through Custom Service.

A requirement does not become Custom Service merely because several Standard Add-ons are combined. If each operation fits its applicable Standard scope, the combined workflow can still consist entirely of Standard Add-ons.

Likewise, the words custom field or database column do not automatically establish a custom project. The requirement should first be tested against the supported Advanced Data Mapping or Advanced Database Mapping boundary. Custom Service becomes relevant when the desired result goes beyond what those supported controls can deliver.

Add-ons and Custom Service Solve Different Problems

Add-ons handle bounded data-processing requirements. Custom Service owns broader tailored or non-standard work when the requirement cannot be satisfied within supported migration and Standard Add-on behavior.

Custom Service becomes relevant when the required operation no longer fits the bounded Standard Add-on model. Typical signals include unsupported third-party application or extension data, bespoke scripts or API processing, non-standard relationships or migration logic, and Add-on functionality that must be tailored or engineered beyond the Standard catalog. Broader non-standard scope is addressed through the dedicated Custom Service guidance; the important decision here is recognizing when an Add-on alone no longer describes the work.

A migration can also use Standard Add-ons within a broader Custom Service scope. The presence of Custom Service does not change what each Add-on does; it changes the broader handling required for the project-specific work.

How Add-ons Relate to Entity Points and Pricing

Entity Points and Add-ons answer different planning questions.

Entity Points measure counted migration capacity for Products, Customers, Orders, and Blog Posts. Add-ons control specific supported processing behavior. An Add-on does not create a new Entity Points weight, and a non-counted data type does not become counted merely because an Add-on is used with it.

The fixed Standard Add-on prices shown in the catalog above are separate from Entity Points capacity. Tailored and Custom Add-ons do not use those fixed Standard prices as final project quotes because their additional work is reviewed under Custom Service.

When an eligible Add-on is added later to the same purchased migration, the applicable upgrade follows the difference-only pricing principle. The Add-on changes the service package for that migration; it does not change the fixed Source Platform-to-Target Platform path or restart the service duration.

How to Evaluate Add-on Suitability for a Real Requirement

A useful Add-on evaluation starts with the desired Target Store outcome rather than with the Add-on names. The business requirement can then be decomposed into the decisions that the four stages actually control.

Evaluation question	What the answer reveals
Which records should participate in the result?	Whether Data Filter is needed.
Is the source value already correct but intended for a different supported target field?	Whether Advanced Data Mapping is needed.
Does the requirement depend on an underlying database field or column, and are both platforms open-source?	Whether Advanced Database Mappingshould be evaluated.
After mapping is complete, does the target value itself need to change?	Whether Data Transformation is needed.
What evidence will prove the resulting value, destination, relationship, and business meaning are correct?	What must be validated before the requirement can be considered successful.

The language used in a requirement often provides useful clues. Words such as include, exclude, only, or condition usually describe record selection. Map, place, send, or destination usually describe field mapping. References to database columns, platform-specific fields, or custom fields may require Advanced Database Mapping when the complete platform path and supported scope qualify. Calculate, normalize, append, remove, convert, or restructure usually indicate value transformation.

These are diagnostic signals, not automatic approvals. A field with the right name may still have an incompatible value type. A custom field may fit a Standard mapping Add-on, while another custom field may depend on unsupported logic and require Custom Service. An open-source-to-open-source migration may qualify architecturally for Advanced Database Mapping while the specific database column remains outside supported scope.

The strongest requirement therefore describes five things together: the affected data type and records, the source value, the intended target destination, any final value rule, and the evidence that will confirm the outcome. Once those elements are explicit, the Add-on combination can be evaluated against the supported boundaries rather than selected by feature name alone.

This outcome-first approach prevents two opposite mistakes. It avoids escalating a supported requirement into Custom Service merely because several controls are involved, and it also avoids stretching a Standard Add-on beyond its supported function simply because its name sounds related to the requirement.

Conclusion

Next-Cart Add-ons are most useful when they are understood as distinct stages in one supported data-processing model rather than as an unrelated feature list. Data Filter selects records, Advanced Data Mapping changes supported field destinations, Advanced Database Mapping extends eligible mapping to supported fields and database columns when both the Source Platform and Target Platform are open-source, and Data Transformation changes the resulting target values.

Their fixed processing sequence is part of the decision. Each applicable stage works with the result established earlier in the sequence, which means combined requirements should be designed around the final Target Store outcome and validated as one coordinated workflow.

Standard Add-ons remain bounded supported capabilities. When the required function needs modification, expanded logic, bespoke engineering, or unsupported handling, the requirement moves into Tailored Add-on, Custom Add-on, or broader Custom Service scope rather than stretching the Standard capability beyond its intended boundary.

Common Questions

How can a business tell whether it needs one Add-on or several?

Break the requirement into record selection, field destination, database-level representation, and final value change. If the business outcome contains more than one of those operations, several Add-ons may be appropriate. The number of Add-ons is less important than whether each stage solves a distinct supported part of the same outcome.

Can several Standard Add-ons be used in the same migration without Custom Service?

Yes. Combining several Standard Add-ons does not by itself make the migration a Custom Service case. Each operation must remain within the supported Standard scope for its Add-on, the stages should form one coherent processing strategy, and the combined result should be validated against the intended business outcome.

Does the order of Add-ons matter when several are used together?

Yes. The processing sequence is Data Filter, Advanced Data Mapping, Advanced Database Mapping, then Data Transformation. Each applicable stage works with the result established by the preceding stages, so overlapping rules should be planned as one sequence.

Is Advanced Database Mapping available when only the Target Platform is open-source?

No. Both the Source Platform and the Target Platform must be open-source for Advanced Database Mapping to be available. If either platform is non-open-source, the Add-on is not available.

What is the difference between Advanced Data Mapping and Data Transformation?

Advanced Data Mapping changes the compatible target destination for a supported source field without changing the value as part of the mapping operation. Data Transformation changes the selected target field value itself. When both are used, mapping establishes where the value belongs before transformation applies the final supported value-changing rule.

Can two mapping Add-ons affect the same target destination?

They can participate in a requirement that converges on the same destination, but the rules must be designed as one sequence rather than as independent mappings. Advanced Database Mapping runs after Advanced Data Mapping, so the value established by the later applicable mapping stage is the value available to Data Transformation.

Can a custom field or database column still fit a Standard Add-on?

Potentially. A custom field or database column should first be evaluated against the supported Advanced Data Mapping or Advanced Database Mapping scope. The word custom does not automatically mean Custom Service, but unsupported or bespoke behavior still requires additional review.

Do Advanced Data Mapping and Advanced Database Mapping support Tax data?

No. Tax data is outside the supported scope of both mapping Add-ons.

Do Add-ons change the Entity Points calculation?

No. Entity Points continue to use the counted Products, Customers, Orders, and Blog Posts model. Add-ons affect supported processing behavior and pricing separately from Entity Points capacity.

When should an Add-on requirement move to Custom Service?

Custom Service becomes appropriate when the requirement exceeds supported Standard migration and Add-on capability, including Tailored or Custom Add-on work and other bespoke or unsupported data-handling logic. The deciding factor is the supported boundary, not the mere presence of several Add-ons, a custom field, or a database column.