Non-standard migration requirements are difficult for a reason that raw record counts cannot reveal: the data often carries meaning that is not visible in the field name alone. A custom Product value may drive search, pricing, or fulfillment. An external Order identifier may connect the Store to accounting. An application-owned record may represent a subscription, loyalty balance, marketplace seller, or operational workflow.
Moving the value without understanding that role can create a Target Store that looks complete but no longer supports the business. Within Next-Cart Migration Services, Custom Service addresses this gap by turning a non-standard requirement into an agreed migration outcome, with defined source evidence, target representation, tailored work, and acceptance criteria.
The goal is not to label an entire project as custom. It is to identify the specific areas where supported behavior and Standard Add-ons are insufficient, then define what a workable migrated result should mean.
Identify Why the Requirement Is Non-Standard
A requirement may need Custom Service because of its source, structure, logic, relationship, or target destination.
| Source of difficulty | Underlying question |
|---|---|
| Custom Platform | How can the source or target data model be understood and accessed? |
| Custom fields or tables | What business meaning do the values carry, and which records own them? |
| Application, plugin, module, or extension data | Is the data authoritative, and what future workflow needs it? |
| External identifiers | Which system relationship must remain connected after migration? |
| Bespoke transformation | How should values or records be combined, split, normalized, or restructured? |
| Non-standard relationships | How should ownership and references be represented in the Target Platform? |
| Modified or new Add-on behavior | Why can the available Standard Add-on not produce the required output? |
| Target limitation | What is the closest workable representation, and what implementation remains separate? |
These questions make the custom scope explainable. “Migrate all custom data” does not. A useful requirement identifies the affected records, continuing business purpose, intended Target Store result, and evidence that will prove success.
Custom Platform Work Begins With a Data Model
A Custom Platform may be the Source Platform, Target Platform, or both. The challenge is not simply establishing access. The migration must determine how the Store represents Products, Customers, Orders, content, relationships, and supporting structures.
Useful source evidence may include:
- schema or export descriptions;
- representative Products, Customers, Orders, and content;
- primary and foreign keys;
- Category and navigation relationships;
- custom status or type values;
- media and file references;
- information about external systems;
- examples of the business outcomes that must continue.
The review should then compare that source meaning with Target Platform capability. Some records may have a direct equivalent. Others may need transformation, field mapping, a custom target structure, or exclusion with a documented alternative.
Custom Service does not make every target representation possible. It creates a disciplined way to determine what can be migrated, what must change, and what the customer should expect.
Treat Third-Party Data as an Ownership Problem
Stores often depend on data created by applications, plugins, modules, extensions, or connected services. The presence of a table or field does not prove that it should be migrated. Some records are authoritative. Others are caches, logs, derived values, or remnants from abandoned functionality.
The custom review should establish:
- which system owns the data;
- which business process uses it;
- whether it remains authoritative;
- which migrated record it belongs to;
- what the Target Store or connected system should do with it;
- how the result will be validated.
This ownership test is more reliable than copying every non-standard field. Data without a future owner may create clutter or conflict. Data with a continuing operational role may be critical even when it occupies only one field.
Examples include:
- subscription identifiers connected to Products or Customers;
- loyalty balances connected to Customer identity;
- marketplace seller ownership connected to Products and Orders;
- fulfillment references connected to Order lines;
- PIM identifiers connected to Product records;
- reporting classifications connected to Products, Customers, or Orders.
Preserve External Identifiers Through Their Relationships
An external identifier is useful only when its relationship survives. Copying an ERP Product ID into an arbitrary text field may preserve the characters while breaking the process that depends on them.
The custom scope should define:
- the system that owns the identifier;
- the migrated record it references;
- uniqueness and format requirements;
- whether the value can change;
- the compatible target destination;
- the integration or reporting process that will use it;
- the evidence needed to confirm the relationship.
For example, preserving an Order reference may require more than migrating the header value. Customer service, fulfillment, or accounting may need the reference connected to the correct Order, line items, and historical context.
Integration deployment remains separate unless it is expressly included. Custom Service can preserve the migration-side data and relationship defined in the accepted scope. It does not automatically build or operate every system that later consumes that data.
Define Bespoke Transformation by Meaning
Custom migration logic may be needed when standard behavior cannot produce the intended result. Common patterns include:
- combining several source fields into one target field;
- splitting one source value across several target fields;
- normalizing inconsistent values;
- converting source statuses into target statuses;
- reshaping application-owned records;
- preserving non-standard relationships;
- matching records through project-specific identifiers;
- applying rules that are unavailable through Standard Add-ons.
The transformation should be described as a rule with examples and exceptions.
Weak requirement:
Fix the Order statuses.
Stronger requirement:
Convert each approved source Order status to the defined target status, preserve the original source status for audit where agreed, and validate examples from completed, cancelled, refunded, and partially fulfilled Orders.
The stronger requirement explains the source condition, target result, and proof. It can be scoped, quoted, implemented, and accepted.
Know When an Add-on Becomes Custom
Standard Add-ons solve bounded supported requirements:
- Data Filter chooses which records migrate by applying field-based conditions to each data type;
- Advanced Data Mapping remaps supported source fields to compatible target fields;
- Advanced Database Mapping maps supported fields and underlying database columns to compatible target fields or columns only when both the Source Platform and Target Platform are open-source;
- Data Transformation transforms selected target field values during migration.
Custom Service becomes relevant when:
- a Standard Add-on must be modified, creating a Tailored Add-on;
- no Standard Add-on fits, creating a need for a Custom Add-on;
- the underlying records or relationships are unsupported;
- the requirement needs bespoke logic beyond the Add-on’s available behavior.
An Add-on can remain part of a Custom Service project. The Add-on addresses a focused capability, while Custom Service defines the wider non-standard outcome.
Build the Scope Around Evidence
A Custom Service request should supply enough evidence to define both feasibility and acceptance.
| Evidence | Why it matters |
|---|---|
| Source and Target Platform details | Establishes the migration path and platform context |
| Representative source records | Shows actual values, structures, and relationships |
| Data owner and business purpose | Explains why the non-standard data should survive |
| Intended Target Store result | Defines the required representation |
| Transformation or matching rules | Makes tailored logic testable |
| Related applications or external systems | Reveals dependencies outside standard platform records |
| Exceptions and failure cases | Prevents the scope from covering only ideal records |
| Validation samples and owner | Defines how acceptance will be decided |
| Entity Points Plan and purchased Add-ons | Separates capacity and existing enhancements from new custom work |
The evidence should include difficult cases, not only clean examples. A custom rule that works for ordinary Products may fail on Products with missing identifiers, duplicate values, or unusual relationships.
The accepted scope should state what will be extracted, transformed, related, or delivered. It should also state what is excluded, what depends on Target Platform capability, and which implementation responsibilities remain separate.
Separate Migration Handling From Target Implementation
Custom Service can define tailored migration handling. It does not automatically include:
- theme or storefront design;
- application or extension installation;
- integration development and deployment;
- payment, shipping, tax, or email setup;
- complete workflow reconstruction;
- operational configuration;
- every source behavior the Target Platform cannot support.
This separation is not merely contractual. It protects the migration decision. A record can be migrated correctly while the target workflow that uses it is not yet implemented. Conversely, a target application can be installed while the migration has not preserved the data it needs.
The scope should show the handoff. For example, an external identifier may be migrated into an agreed target field, while separate integration work connects that field to the ERP.
Set Realistic Expectations for Platform Differences
Custom Service cannot force two platforms to behave identically. Product options, Customer groups, Order states, content hierarchies, URLs, and application data may have no direct target equivalent.
The workable outcome may be:
- direct preservation;
- transformation into a target-supported structure;
- field-level mapping;
- partial preservation of the business meaning;
- export for separate use;
- exclusion with a documented replacement plan.
The appropriate result depends on the business purpose and Target Platform capability. Exact imitation is not always the strongest objective. A simpler target representation can be better when it preserves the required outcome without carrying obsolete source logic forward.
Understand Scope, Execution, and Price Separately
Custom Service defines tailored work. Expert Handle defines whether expert-led execution of the agreed migration actions is also included.
A Custom Service project may therefore be:
- customer-led, with the tailored work included and the customer performing migration actions; or
- expert-led, with Expert Handle included in the accepted scope.
The displayed Custom Service amount starts from the Standard Service price for the selected Entity Points Plan. That amount establishes the capacity floor. The final total adds the agreed customization-work quote, purchased Add-ons where applicable, Expert Handle when included, and other accepted scope-specific costs.
When custom work is added to a migration that has already been purchased, the accepted quote changes the total migration value. The amount already paid remains recognized, and only the additional difference is charged. The same principle applies to Tailored and Custom Add-ons.
The final price cannot be established responsibly until the non-standard outcome is clear enough to scope. Accepting and purchasing the quoted upgrade integrates the work into the same migration; it does not create a new path or extend the one-year service duration.
Validate the Tailored Outcome
Custom work needs custom acceptance evidence. Generic count checks are insufficient when the requirement depends on meaning, transformation, or relationships.
Validation should compare:
- source example;
- agreed transformation or handling rule;
- Target Store representation;
- linked records or external identifiers;
- expected business behavior;
- exception handling;
- Pass, Watch, or Block decision.
The customer remains responsible for final verification. This is particularly important for custom work because the acceptance standard often depends on business knowledge that cannot be inferred from the source schema alone.
A Watch decision should identify the remaining uncertainty, its business consequence, the evidence still required, and the person responsible for resolving it. Without that interpretation, custom validation becomes a list of observations rather than a defensible acceptance decision.
Conclusion
Next-Cart Custom Service handles the parts of a migration that require individual interpretation, tailored logic, modified Add-ons, Custom Platform analysis, non-standard relationships, or a designed target representation.
The strongest custom scope begins with meaning and evidence. It identifies who owns the data, what business purpose continues, how the Target Store should represent the result, which migration work is required, what implementation remains separate, and how acceptance will be proven.
Custom Service is not a promise to recreate every source behavior. It is a structured way to reach the closest workable, testable outcome when supported behavior and Standard Add-ons are not enough.
Common Questions
Is Custom Service only for Custom Platforms?
No. It also applies to custom fields, third-party data, external identifiers, bespoke logic, Tailored Add-ons, Custom Add-ons, and other non-standard requirements.
Does every custom field require Custom Service?
Not automatically. The decision depends on whether the field is supported, what business meaning it carries, where it should be represented, and whether available mapping behavior is sufficient.
How is Custom Service different from a Standard Add-on?
A Standard Add-on solves a bounded supported filtering, transformation, or field-mapping need. Custom Service addresses modified, unsupported, or bespoke requirements that need tailored scope.
Does Custom Service always include Expert Handle?
No. The project may remain customer-led. Expert Handle is included only when expert-led execution is part of the accepted custom scope.
Can Custom Service reproduce every source behavior exactly?
No. The result depends on source data condition, Target Platform capability, the accepted scope, and the evidence required for customer approval.
What evidence is needed for a Custom Service request?
Representative records, ownership and business purpose, intended target representation, transformation or relationship rules, exceptions, related systems, and validation examples are needed.
Is Target Platform implementation included automatically?
No. Design, application installation, integration deployment, and operational configuration remain separate unless expressly included in the accepted scope.
Why is the Custom Service amount a starting price?
It establishes the Standard Service capacity floor for the selected Entity Points Plan. The final total depends on the agreed custom work, Add-ons, Expert Handle when included, and other accepted scope-specific costs. For later accepted work, the amount already paid remains recognized and only the additional difference is charged.