ERP Migration & SelectionFree calculatorPDF, Excel, Word exportQAD Adaptive ERPDiscrete Manufacturing

QAD Customization Migration Effort Calculator

The biggest swing factor in a QAD upgrade or move to a newer edition is how many customizations survive. This calculator turns an inventory of custom items into hours, person-days and cost, and shows how retiring items changes the bill.

Your numbers

items

Field, label or small report changes.

items

Modified programs, validation logic, interfaces.

items

New modules, heavy integrations, workflow replacements.

hours
hours
hours
30 %

Customizations you will drop because standard functionality now covers them.

% of build
%
$ per hour

Your results

Total hours with contingency
1,519.56
Estimated cost
$144,358
Gross build hours before retirement
1,340
Build hours after retirement
938
Testing hours
328.3
Person-days
190 days

Planning estimate only. Replace hours per item with your own history and validate the inventory by code scan before committing a budget.

Save results:

Total hours vs share of customizations retired

Sweeps Share retired or replaced by standard from 0 to 90, holding your other inputs fixed.

Customization inventory review

Optional expert review of how you classified custom items and where retirement is most likely.

Optional. The tool and every export work without this. No spam.

How to use it

Start with an inventory of what was changed: custom programs, modified standard programs, reports, interfaces and database additions. Classify each as simple, medium or complex, using consistent rules that you write down. Enter the counts and the hours your team really takes per class. Then decide the share you can retire because standard functionality has caught up, and slide the retirement control to see how the total moves. Add testing overhead and contingency that match your risk appetite.

  • Classify with written rules, not gut feel
  • Use hours from your last upgrade where possible
  • Challenge every item: does anyone still use it?
  • Keep interfaces separate if a partner builds them

The method

Gross hours are the sum of count times hours for each class. Retirement removes a percentage of that work. Testing is a percentage of the remaining build hours, because every retained change must be regression tested. Contingency is applied to build plus test. Person-days divide by eight, and cost multiplies total hours by the blended rate. The method is deliberately simple so every line can be challenged in a steering meeting.

Reading the result

The chart is a straight line, which makes the point: every ten percent of customizations retired removes the same slice of effort. Compare the cost of re-implementing an item with the cost of changing a business process to use standard behaviour. Items used by a single person once a quarter are prime retirement candidates. If the total is far above your budget, look first at the complex class, where a handful of items often hold half the hours.

Common mistakes

Counting only code and missing reports, labels, interfaces and database triggers produces a low estimate. Assuming hours per item from a vendor rate card ignores the learning curve on a new platform. Skipping data conversion, training and cutover from the budget is common, since they are not customizations at all. Finally, retire percentages should come from a reviewed list, not a target someone hopes to hit.

Frequently Asked Questions

How do I find all customizations?

Combine three sources: a scan of custom source code and configuration, a list of modified standard objects, and interviews with power users. Each source misses things the others catch, so use all three before classifying.

What is a realistic retirement rate?

It depends on how old the current release is. Systems several versions behind often retire a meaningful fraction because standard functionality has caught up, but only a reviewed list can tell you your number.

Does this include data migration?

No. It sizes customization work only. Data conversion, integration testing with other systems, training and cutover need their own estimates and should be added to the project budget separately.

Why add a contingency?

Hidden dependencies and rework are normal in upgrades. A contingency of 15 to 30 percent is common practice, and the number should shrink as the inventory is proven by actual code analysis.

Netray works with ERP specialists on customization inventories and AI-assisted code analysis. If you want a second opinion on your estimate, get in touch.

Talk to an ExpertExplore More Free Tools

Related Tools

Other ERPs

QAD Subscription vs Perpetual License TCO Calculator

Model the multi-year total cost of owning QAD on a perpetual license plus maintenance versus a cloud subscription, and find the break-even year.

Other ERPs

IFS Project Earned Value Calculator

Turn percent complete, planned progress and actual cost from your IFS project into CPI, SPI, estimate at completion and the to-complete performance index.

Other ERPs

IFS Shop Order Lead Time Calculator

Estimate how long a shop order really takes through its routing, and what share of that time is actual work, as a check on lead times stored in IFS.

More ERP Migration & Selection tools

See all
Back to All Tools