Prepare Custom Service Requirements

Prepare Custom Service Requirements

Prepare a Custom Service requirement when the expected result cannot be implemented through standard configuration or available Standard Add-ons.

Custom Service covers requirements that exceed supported Standard behavior, including unsupported data, third-party app, plugin, or module data, bespoke logic, non-standard relationships, schema engineering, external-system handling, and other agreed custom work. It is also required when CSV, XLS, or XML is selected as the Source Platform, and when a required Source or Target Platform is outside the standard supported directory.

Moving an existing migration from Standard or Managed Service to Custom Service is therefore a functional scope escalation. The Upgrade must carry approved non-standard requirements such as tailored configuration, specialized schema adjustments, unique business rules, unsupported platform handling, or other bespoke developer work; it is not a nominal tier relabeling.

File-based sources and Custom Platforms

CSV, XLS, and XML

CSV, XLS, and XML are file-based Source Platform selections handled through Custom Service. Their included file workflow migrates Products only. Follow the matching CSV, XLS, or XML Product file guide for the Product input.

If the project also requires Customers, Orders, another entity type, non-standard relationships, or special business logic, describe each additional requirement in the Custom Service request. Those requirements are assessed and developed for the individual migration rather than assumed to be supported by an extra file. File-based projects follow the same Custom Service quote, approval, and purchase workflow as other Custom Service projects.

Example: CSV to Shopify with additional scope

A CSV → Shopify project uses the CSV Source Platform and the Shopify Target Platform. The included CSV file workflow migrates Products. If the project must also migrate Customers, Orders, or apply project-specific business logic, add those requirements to Custom Requirements so Next-Cart can scope and develop the additional handling. The project follows the same Custom Service quote, approval, and purchase workflow as any other Custom Service request.

Because CSV has no Source Store URL, the Shopify Target URL locks when Connect Stores is saved and the migration advances to Configuration. Review Store URL Locking and Store Identity before continuing.

Platform not present in the supported directory

A Source or Target Platform that is not present in Next-Cart’s standard supported directory is handled as a Custom Platform project. Define the platform, available source access, data structures, data conversion requirements, relationships, expected Target result, and validation criteria. Next-Cart then scopes the technical extraction and migration approach for that project.

Select CSV, XLS, or XML when the project is intentionally based on that Product file workflow. If the project instead depends on platform-specific extraction, conversion, or broader source data from an unlisted platform, define the actual platform and requirements as Custom scope.

Check standard configuration and Add-ons first

Standard configuration and the four Standard Add-ons cover defined capabilities. Test supported Standard handling first. Use Custom Service for the portion that remains unsupported, needs a Standard Add-on to be tailored, or requires bespoke Custom Add-on functionality.

Before you prepare a Custom Service requirement

Confirm whether the requirement is covered by one of these paths:

Capability	Use it when	Custom Service threshold
Standard data selection	You need to include supported data types.	The required data is not exposed as a supported data type or supported source record set.
Additional Options	You need supported target-data clearing, name cleanup, description-image handling, identifier preservation, or SEO URL behavior.	The required behavior exceeds the option shown for the migration configuration.
Advanced Attributes Mapping	You need supported Language, Customer Group, or Order Status mapping.	The target value or mapping behavior cannot be represented through the standard mapping control.
Data Filter	You need field-level conditions per data type to control which records migrate.	Required fields, operators, logic, relationships, or external data are unavailable.
Data Transformation	You need a supported value change on retained records before mapping.	The required expression is unavailable, depends on external data, or requires bespoke/multi-record logic outside Standard behavior.
Advanced Data Mapping	You need to redirect a supported source or transformed value to a different compatible target field without changing it again as part of mapping.	The required field or destination is unsupported, value compatibility cannot be satisfied, or the requirement needs non-standard behavior.
Advanced Database Mapping	You need supported source or transformed value/database-column mapping, the selected Source setup supports Advanced Database Mapping, and the Target Platform is supported as a database-mapping destination.	The selected Source setup or Target Platform is unsupported, the field/column or destination is unavailable, value compatibility cannot be satisfied, or bespoke schema behavior is required.

Choose the Custom Service operation mode

A new Custom Service purchase also requires an execution-responsibility decision.

Operation mode	What to plan for
Self-Execute	The customer operates the migration through the Dashboard after the approved Customization is prepared and verified. Define enough requirements and pass conditions to verify the tailored behavior before execution.
Expert Handle	Next-Cart engineers manage and execute the agreed migration work. Include scheduling, access, dependencies, and execution expectations in the scope. The additional engineering fee is included in the final itemized quote.

The operation mode changes execution responsibility, not customer access. The customer retains Dashboard visibility and operational access to inspect, manage, and use the available execution controls. With Expert Handle, customer-initiated execution should remain aligned with the agreed operating schedule because Next-Cart is responsible for the agreed execution.

Requirements that usually need Custom Service

• data stored in third-party apps, plugins, modules, or extensions;
• custom fields whose required handling remains outside supported Advanced Data Mapping or Advanced Database Mapping scope;
• database tables or columns that remain unsupported after Advanced Database Mapping eligibility and support are checked;
• tailored or bespoke Add-on behavior that modifies or exceeds a Standard Add-on;
• multi-record or bespoke conditional processing outside supported Data Transformation;
• bespoke relationship reconstruction;
• unsupported filter logic;
• custom platform extraction or target handling;
• data from external systems such as ERP, CRM, marketplace, subscription, or loyalty services;
• target output requiring custom code, custom storage, or non-standard placement.

Extension, app, module, and plugin data

Treat application-owned data as a separate migration requirement. Identify where the data is stored, which records and relationships must survive, and which Target Store application or structure will consume it. Selecting a related standard entity does not automatically include extension-owned tables, API objects, custom fields, or application behavior.

WooCommerce Subscriptions, attachments, wholesale pricing, and abandoned carts

These structures are not interchangeable with ordinary Products, Customers, or Orders. Their support depends on the source implementation, the target extension or data model, and the exact relationships that must be recreated.

For each requirement, document the responsible plugin or storage structure, the records and relationships involved, and the accepted target representation. Do not assume that the standard WooCommerce path includes subscription renewal behavior, product attachments, wholesale-pricing structures, or abandoned-cart state merely because related Customers, Products, or Orders migrate.

WooCommerce bundle, composite, and custom-option Products

Define the selling behavior that must be preserved, not only the source Product type name. A Target Store may represent the requirement through a native Product type, variation structure, extension-owned model, or approved custom representation.

Do not flatten bundle, composite, or custom-option behavior into ordinary variations unless that transformation is explicitly accepted and validated.

Shopify metafields and storefront output

Migrating a metafield or custom field does not automatically make its value visible on the storefront. Define the target resource, field definition, data type, and the theme, application, or component that will consume the value.

Treat data placement and storefront presentation as separate requirements. If storefront rendering requires custom theme or application work, include that work explicitly in the approved scope.

Shopify Gift Cards

Gift Card requirements need explicit qualification because the business object, customer association, Order relationship, balance state, and redemption behavior are separate concerns. Do not infer Gift Card support from ordinary Coupon, Customer, or Order support.

Document the required historical and active-state behavior, the accepted Target Store representation, and the validation evidence required before approving the scope.

Full-site replication

A data migration is not a full clone of a Source Store. Themes, page layout, application behavior, checkout logic, payment configuration, shipping logic, storefront navigation, external integrations, and other operational behavior may require separate setup or Custom Service work.

If the objective is to reproduce the complete business experience, split the requirement into explicit data, application, URL, storefront, and integration outcomes and scope each non-standard portion separately.

Prepare the requirement

1. Name the requirement

   Use one clear name for one requirement.

2. Identify the affected data type

   State whether the requirement affects Products, Categories, Customers, Orders, Reviews, Coupons, Pages, or another data area.

3. Identify the source location

   Provide the field name, export column, table, metafield, app area, plugin table, module, API property, or admin location.

4. Describe the target result

   State where the data should appear and what the user should be able to see, search, edit, or validate.

5. Write the logic as a testable rule

   Use an if/then statement where possible. Include fallback behavior.

6. Provide representative examples

   Include at least three normal examples and three edge cases where the data allows it.

7. List dependencies

   Identify required credentials, exports, permissions, apps, plugins, modules, custom fields, or target settings.

8. Define pass conditions

   State which records and fields must match, what differences are acceptable, and what would block sign-off.

9. Choose the correct submission path

   For a new Custom Service purchase, enter the requirement in Checkout → Custom Requirements, add supporting attachments, and select Request a Quote. For an existing migration, use the supported Custom Service upgrade or scope-review path. Keep follow-up clarification and evidence in the order or support thread Next-Cart provides for that request.

Requirement template

Field	What to provide
Requirement name	Short, unique name.
Affected data type	Data area affected.
Source location	Field, table, export, app, plugin, module, API property, or admin location.
Target destination	Native field, custom field, note, tag, table, reference, or target behavior.
Logic	Testable rule, including conditions and fallback behavior.
Normal examples	Representative source records and expected outputs.
Edge cases	Complex, empty, duplicate, unusual, or risky records.
Dependencies	Access, permissions, exports, integrations, target settings, or applications.
Validation	Samples, pass conditions, acceptable differences, and blockers.

Example requirement

Requirement: Merge an external ERP reference into a project-specific Product relationship
Affected data type: Products
Source location: ERP API data that is not part of the supported migration source
Target destination: Agreed project-specific target relationship
Rule: Match the ERP reference to the migrated Product by the approved identifier and create the agreed target relationship only when the source match is unique.
Validation: Check normal Products, a missing ERP reference, a duplicate ERP reference, and a Product whose source identifier changed.

Assessment, quote, and purchase

For a new Custom Service purchase, Request a Quote creates a Draft order. Next-Cart assesses the submitted requirements and itemizes each approved custom modification so its functional scope and price can be reviewed separately. The customer and Next-Cart then align the technical rules, execution responsibility, dependencies, and expected timeline.

After the finalized quote and order configuration are approved, the Draft moves to Pending Payment. Complete the payment workflow only when the itemized scope matches the agreed requirements. After the order becomes Paid, approved Customization is prepared and verified; an automated readiness email confirms when the project is configured for execution.

For an existing migration, approved new custom scope follows the supported Upgrade path. Use Purchase a Migration Upgrade to open the project from Statistics → View Upgrade Option and configure the supported upward change. Use Orders for differential billing, supported upgrade direction, and how a successful custom-work Upgrade is integrated into the existing migration.

Expected result

A complete Custom Service requirement should make it possible to determine:

• what data or behavior is required;
• why standard configuration and purchased Add-ons are insufficient;
• where the source data exists;
• what the target result must be;
• which dependencies affect implementation;
• how the result will be validated.

Verify the requirement

Check	Pass condition
Capability boundary	The requirement is not already covered by standard configuration or a purchased Add-on.
Source evidence	Field names, locations, records, screenshots, or exports are provided.
Target expectation	The expected target result is specific and testable.
Examples	Normal and edge-case records are included.
Dependencies	Required access, applications, permissions, and target preparation are listed.
Validation	Pass conditions and blockers are defined.

Failure handling

Issue	What to do
The source location is unknown	Ask the source store owner, developer, or app provider to identify the field, table, export, or API property.
The target destination does not exist	Prepare the required target field or define an approved fallback.
The requirement is too broad	Split it into separate testable requirements.
Examples are unavailable	Collect representative records before requesting implementation.
The requirement may be covered by an Add-on	Check Standard Add-ons first. For Advanced Database Mapping, confirm platform eligibility and schema support before escalating.
The result cannot be validated	Define concrete sample records and pass conditions before implementation begins.

Database-backed and non-standard sources require Custom scope definition

A database engine such as PostgreSQL, MySQL, Microsoft SQL Server, or another SQL-compatible system is not a generic Source Platform selection. Direct-database access should therefore be described as a Custom Service requirement unless the data is already represented by a supported platform and its documented connection method.

For a database-backed requirement, provide the database engine and version, access method, relevant schemas or tables, the business entities stored there, stable identifiers and relationships, representative field types, expected target outcomes, and any transformation rules. Do not request migration by choosing a different platform merely because it uses the same database technology.

The same principle applies to non-standard exports and extension-owned data. Subscriptions, abandoned carts, gift cards, invoice documents, downloadable assets, attachments, plugin or app records, and other specialized structures need an explicit source, target consumer, and acceptance criterion when they fall outside the supported standard path.

Next Steps

For a new Custom Service purchase, continue to Purchase a Migration, enter the prepared requirements and attachments, choose the operation mode, and select Request a Quote. For a changed requirement on an existing migration, use Purchase a Migration Upgrade after the Custom requirement is sufficiently defined, or use Custom Service Escalation when the scope still requires review.