Entity Points

Raw record counts can make migration capacity look simpler than it is. A Product, Customer, Order, and Blog Post do not contribute equally to the counted requirement, and a Store contains many important structures that do not independently consume Entity Points at all.

Entity Points are the weighted capacity framework used across Next-Cart Migration Services. They solve one planning problem: converting four Entity Points-counted data types into a weighted capacity requirement. They do not score complexity, guarantee compatibility, limit the migration to the quantities entered during purchase, or prove that the Target Store will be usable.

That boundary is essential. When Entity Points are treated as a complete measure of the project, a predictable high-volume Store can appear unnecessarily complex, while a low-volume Store with custom relationships can appear deceptively simple.

Distinguish Capacity From Migration Difficulty

Entity Points count:

• Product;
• Customer;
• Order;
• Blog Posts.

Other supported data may still be part of the migration, including Taxes, Manufacturers, Categories, Reviews, Coupons, and CMS Pages. Those structures can be critical to the result even though they do not independently consume Entity Points.

Migration difficulty can also come from:

• Product option and variant relationships;
• custom fields or tables;
• application, plugin, module, or extension data;
• external identifiers;
• target data-model limitations;
• Add-on or Custom Service requirements;
• validation and launch dependencies.

Two Stores can require the same Entity Points capacity and still need different migration approaches. Capacity describes counted volume. Complexity describes the work needed to preserve meaning and produce an acceptable result.

Convert Eligible Records Into Weighted Capacity

Each Entity Points-counted data type has a locked weight:

The calculation is:

Entity Points
= (Product x 1.0)
+ (Customer x 0.5)
+ (Order x 0.8)
+ (Blog Posts x 0.6)

Assume a Source Store contains the following estimated quantities:

The estimated requirement is 480 Entity Points. A 500-point plan could cover that estimate with 20 points of headroom. A 1,000-point plan would leave 520 points of headroom.

The arithmetic is straightforward. The planning judgment lies in whether the quantities are realistic and how much additional activity the Source Store may create before migration is complete.

Treat the Purchase Estimate as a Forecast

The quantities entered during purchase support Entity Points estimation and plan selection. They do not create automatic record filters.

If 200 Products are entered but the selected source scope contains 260 scanned Products, the migration is not instructed to stop at record 200 merely because of the estimate. Actual successfully migrated counted records consume the available capacity.

This produces three different numbers:

Keeping these values separate prevents two common mistakes. The first is assuming that the estimate is a hard migration limit. The second is assuming that unused capacity disappears because the initial estimate was lower.

If only selected records should migrate, the requirement must be defined through Data Filter using field-based conditions for each relevant data type, or reviewed as custom filtering when available behavior is insufficient.

Plan for Variance and Source Store Growth

Estimates often differ from actual consumption because the source inventory was incomplete, the Store continued trading, or overlooked Blog Posts, Customers, or Orders entered scope.

Suppose a 1,000-point plan was selected for the 480-point estimate above. If actual consumption reaches 800 Entity Points, the migration remains within the plan and 200 points remain available.

The original estimate did not prevent the additional eligible records from being migrated. The plan capacity remained the practical boundary.

Headroom is particularly useful when:

• the Source Store remains active during preparation;
• record counts were obtained from partial reports;
• historical data was initially excluded from the estimate;
• Blog Posts or archived Orders are easy to overlook;
• later migration activity is expected before launch.

Headroom should still be intentional. Purchasing a much larger plan does not solve scope ambiguity, custom data, or weak validation.

Understand What Happens When Capacity Is Exhausted

Actual consumption follows this counted data sequence:

Product -> Customer -> Order -> Blog Posts

If available Entity Points are exhausted before all counted records are migrated, processing pauses at the point the capacity is reached. A higher Entity Points Plan can then be selected to provide the required additional capacity.

Consider a Store whose actual counted requirement is 1,175 Entity Points:

With a 1,000-point plan, Products use 600 points and Customers use another 300. Only 100 points remain for Orders, enough for 125 Orders at 0.8 points each. The remaining 125 Orders and 125 Blog Posts require additional capacity.

The example shows why capacity planning needs both arithmetic and source knowledge. A small underestimate can affect a later data type because of the consumption sequence.

Do Not Confuse Capacity Sequence With Migration Sequence

The migration process handles supported data in this order:

Taxes -> Manufacturers -> Categories -> Products -> Customers -> Orders -> Reviews -> Coupons -> CMS Pages -> Blog Posts

Entity Points consumption applies only to Product, Customer, Order, and Blog Posts. The two sequences describe different aspects of the same migration:

• migration sequence describes how supported data types are processed;
• Entity Points sequence describes how counted capacity is used.

This distinction explains why Categories or Reviews can be important to the result without appearing as separate Entity Points charges. Their importance is structural, not defined by the capacity formula.

Apply Entity Points to Later Migration Activity

Entity Points are tied to counted records and whether they have already been counted within the purchased migration and its fixed migration path.

The migration action itself does not determine consumption. Continue the Migration with the Last Used Configuration, Continue the Migration with a New Configuration, and Perform a New Migration can all process a mixture of existing and new records. Consumption depends on whether each eligible record has already been counted within the purchased migration and fixed path.

This rule makes remaining capacity useful for later source activity. It also means the project should track newly added Products, Customers, Orders, and Blog Posts when the Source Store remains active.

Use Entity Points in the Right Decision

Entity Points should guide:

• plan selection;
• headroom planning;
• actual capacity monitoring;
• plan upgrades;
• later eligible record growth.

They should not decide:

• Standard, Managed, or Custom Service;
• whether an Add-on is required;
• whether a custom data structure is supported;
• whether Target Platform implementation is included;
• whether the migration result is acceptable.

Those decisions require scope evidence, responsibility analysis, and validation. A precise Entity Points total is necessary for pricing, but it is not a substitute for understanding the data.

This distinction prevents two opposite planning errors. A store can need a larger Entity Points Plan while remaining straightforward to migrate, or it can fit within a smaller plan while carrying custom relationships that require deeper review. Capacity and complexity should therefore be assessed together, but never treated as the same measure.

Conclusion

Within Next-Cart Migration Services, Entity Points convert Product, Customer, Order, and Blog Posts quantities into weighted migration capacity. The purchase estimate helps select a plan, plan capacity defines the available boundary, and actual successfully migrated eligible records determine consumption.

The central planning discipline is separation. Capacity is not complexity. Estimated counts are not filters. Migration sequence is not Entity Points sequence. A later action does not automatically consume points again for records already counted within the purchased migration and fixed path.

With those distinctions in place, Entity Points become a useful planning instrument rather than a misleading score for the entire migration.

Common Questions

Which records count toward Entity Points?

Product, Customer, Order, and Blog Posts are the four counted data types.

How are Entity Points calculated?

Product has a locked weight of 1.0, Customer 0.5, Order 0.8, and Blog Posts 0.6.

Do the quantities entered during purchase limit which records migrate?

No. They support estimation and plan selection. They do not act as record filters.

What happens if actual consumption is higher than the estimate?

Migration can continue while sufficient plan capacity remains. If capacity is exhausted, processing pauses until additional capacity is available.

Can unused Entity Points support later migration activity?

Yes. Remaining capacity can support eligible records migrated later within the purchased migration and fixed path.

Do records consume Entity Points again during a later action?

Not when the same counted records were already recorded within the purchased migration and fixed path. Newly migrated eligible records consume points when they are successfully migrated for the first time.

Do Categories, Reviews, or CMS Pages consume Entity Points?

They do not independently consume Entity Points. They may still be important parts of the supported migration scope and validation.