Customization vs Configuration: What It Really Costs on IBM i

Sound familiar?

The upgrade quote includes a retrofit estimate for your modifications, and the honest answer to "what do they all do?" is "we're not totally sure." The contractor who wrote most of them retired years ago. It's hard to push back on a number when you can't describe what it's paying for.

What's really driving the number

Unknown modifications get priced as risk. A partner who can't tell which programs matter has to assume all of them do, so every modified object gets quoted for analysis, retrofit, and testing. The irony is that in a shop that has been modifying for decades, it's common to find objects nobody has run in years. IBM i can tell you which ones.

What takes the pressure off

• Pull object usage data before the quote is final. DSPOBJD with OUTPUT(*OUTFILE) records each object's last-used date and days-used count, which turns "we're not sure" into a list.
• Treat that list as a strong hint, not a verdict. Check month-end, year-end, and audit jobs before retiring anything that only looks idle.
• Separate modified vendor objects from programs your shop wrote from scratch. They carry very different upgrade risk.
• Ask for the retrofit priced per object, so every modification you retire takes a known amount off the bill.

Sound familiar?

The new package handles standard pricing fine. The problem is the customer-specific pricing and allocation logic your team built over fifteen years. One side of the room wants to go standard and save money. The other side thinks that's exactly how you lose accounts.

What's really driving the number

Both sides are partly right, because not all customization is the same kind of cost. Logic that encodes how you win business is worth paying to keep. Logic that recreates a report the package already has, or preserves a workaround for a limit that no longer exists, is not. Quotes get expensive when all of it gets carried forward at the same price.

What takes the pressure off

• Sort every modification into three buckets: competitive (keep), compliance (keep, but confirm the standard product can't already do it), and habit (retire or replace with configuration).
• Price the keep bucket with upgrade retesting included, so the real cost of each piece of custom logic is visible over the life of the system.
• Ask the vendor which extension points the package supports, such as user exits, APIs, and user-defined fields, so custom logic can sit beside the product instead of inside its code.

Sound familiar?

The vendor is ending support on your release, the upgrade estimate is several times what the last one cost, and most of it is labeled retrofit. It feels like being punished for building the system the business asked for.

What's really driving the number

Retrofit is the bill for every modification coming due at once. Each changed object has to be compared against new vendor code, re-applied, and retested, and skipping releases makes every comparison harder because more of the code underneath has moved. Testing is where estimates most often fall short. The modernization benchmarks on this site point to user acceptance testing taking roughly 40% of budget, not the 20% commonly planned.

What takes the pressure off

• Run fit-to-standard workshops before the retrofit is quoted. Walk each business process through the new release as delivered, and log only the gaps that genuinely matter.
• Retire or replace modifications before the upgrade starts, not during it. Every object removed first is one that never gets retrofitted or retested.
• Set the testing budget at a realistic share up front, rather than paying for it later as post-launch defects.
• After go-live, give every new modification a named business owner and a written reason, so the next upgrade doesn't start from the same place.

Sound familiar?

The system your team built works, but the developer who knows it best is retiring and nobody wants to be the next single point of failure. The package you like covers most of what you do. The rest came back quoted as customization, and it's a big number.

What's really driving the number

The gap gets priced as custom build because the quote assumes every difference is a requirement. Some are. Others are habits the old system taught people because it was built around how the business worked twenty years ago. Customizing a new package to behave like the old system is often the most expensive way to replace it.

What takes the pressure off

• Run vendor demos from scripts built on your real transactions, not the vendor's standard demo, so the gaps you find are real ones.
• For every gap, ask what breaks if the process changes instead of the software. Write the answer down, because "we've always done it that way" isn't a business reason.
• Get each gap item priced separately, so you can drop the ones that don't survive that question.
• Capture why the old logic exists while the retiring developer is still around. The reason behind a rule is often more useful than the code.