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.
There are also path types where Custom Service is mandatory rather than optional. If the Source Platform selection is CSV, XLS, or XML, the migration is handled through Custom Service. The same applies when the requested Target Platform is outside the supported Target Platform list. These paths still use Entity Points for capacity planning, but technical review defines the actual migration scope before the final quote is established.
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;
- Data Transformation changes supported values on the active dataset through supported expressions;
- Advanced Data Mapping routes supported source or transformed values to compatible target fields without changing them during mapping;
- Advanced Database Mapping routes supported data through eligible database tables, fields, or columns when the selected Source setup and Target Platform both support the Add-on and the requested database locations are compatible.
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.
Scoping becomes materially stronger when quoted work is itemized against that evidence. A useful item is not merely a price line; it identifies a functional requirement and the result that will later be evaluated. When unrelated custom needs are bundled into one vague amount, the project loses traceability between cost, tailored work, and acceptance.
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. This is why final Custom Service pricing follows scope definition rather than preceding it: non-standard work cannot be priced responsibly until the requirement is concrete enough to distinguish what is included, what is excluded, and what evidence will prove completion.
Separate Migration Handling From Target Implementation
Custom Service can define migration handling tailored to the agreed scope. 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. Execution responsibility is selected separately from that tailored scope:
- Self-Execute keeps execution of the agreed migration actions with the customer after the approved tailored work is ready;
- Expert Handle includes expert-led execution of the agreed migration actions within the accepted custom scope.
Neither mode removes the need for customer verification. The distinction concerns who performs the agreed migration actions, not who can judge whether the result preserves the intended business meaning.
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 change the expiration of the active access period.
Commercial approval is not execution readiness
Commercial approval establishes the accepted scope and cost. It does not by itself prove that the tailored handling is ready to be relied on during migration execution. The approved custom work still has to be prepared and verified against the accepted requirement before its result can be meaningfully validated.
Treating commercial approval and technical readiness as separate checkpoints protects the project schedule. It prevents a paid custom scope from being mistaken for an execution-ready custom result and makes the readiness decision depend on verified capability rather than financial settlement alone.
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. Self-Execute keeps execution with the customer. 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 non-standard requirements are assessed and itemized before the final custom price is established. 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.
Does a PostgreSQL, MySQL, or Microsoft SQL Server database automatically count as a supported Source Platform?
No. A database engine identifies storage technology, not a standard commerce Source Platform or a known commerce schema. A direct database-backed requirement needs Custom Service scoping unless the data is represented through a supported platform and its documented connection method. Useful evidence includes the application or platform using the database, engine and version, available access, relevant tables and entities, identifiers and relationships, field types, and the intended Target Store result.
How should extension, app, module, or plugin data be scoped?
Treat extension-owned data as a separate source or target-model question rather than assuming it is included with a related standard entity. Identify where the data is stored, which records and relationships matter, how the target represents the same business meaning, and whether the requirement is standard, Add-on eligible, or needs approved Custom scope. Target-side application installation or behavior is not automatically included merely because its data can be migrated.