Pronto Xi Customisations: What to Keep, Refactor, Replace or Retire Before an Upgrade

Before upgrading Pronto Xi, every material customer-specific extension should be reviewed rather than automatically carried forward.

The important question is not:

“Will this customisation still work?”

It is:

“Is it still used, does it still create enough business value, and does that value justify its dependencies, support requirements, testing burden and future cost?”

Some customisations remain essential because they support genuine business requirements that standard functionality cannot adequately address.

Others may have been created years ago for a process that has changed, a report that is rarely used, or functionality that can now be delivered more simply.

And some remain valuable but should not be retained as they are because they have become fragile, poorly documented or difficult to support.

That produces four possible decisions:

KEEP → REFACTOR → REPLACE → RETIRE

The objective is not to eliminate Pronto Xi customisation. It is to ensure that every material customer-specific artefact still earns the complexity it introduces.

Why review Pronto Xi customisations before an upgrade?

Pronto Xi is deliberately extensible.

Pronto Software publishes development and extension capabilities including Rapid Application Development (RAD), its 4GL language, SQL, an SDK, webhooks and Pronto Connect. It also supports customised documents through TrueForm Neo.

That flexibility can be valuable where an organisation has genuinely distinctive operational requirements.

But every customer-specific element can potentially create additional questions during an upgrade:

• Does it still work?
• Does anybody still use it?
• What depends on it?
• Who understands it?
• Does the organisation still have the source or configuration?
• Does newer standard functionality now solve the problem?
• What must be regression-tested?
• What happens if it fails?

Pronto's published implementation methodology explicitly includes customisation, testing and business simulations before go-live, reinforcing the need to validate customer-specific changes as part of significant ERP change.

For CFOs and CIOs, the opportunity is straightforward:

Do not carry historical complexity into the next Pronto Xi environment without first establishing that it still has a business reason to exist.

First, define what you mean by “customisation”

One important distinction is often lost in ERP discussions.

Not all customer-specific changes have the same technical or upgrade risk.

For governance purposes, separate them into categories.

Pronto's current platform documentation confirms support for code-level extension through RAD and SDK tools, external connections through Pronto Connect and webhooks, and document customisation using TrueForm Neo.

Technically, these artefacts are not equivalent.

A modified invoice format does not present the same risk as custom pricing logic that changes sales orders and downstream financial postings.

The governance framework can be common, but the assessment should respect the technical difference.

Build a Pronto Xi customisation register first

You cannot manage what you cannot see.

Before deciding what to retain, establish a register of material customer-specific artefacts.

Do not assume a list of custom programs is enough.

A critical integration, report or configuration may create more upgrade risk than a standalone piece of custom code.

The Pronto Xi customisation decision framework

For every material item, work through this sequence:

Is it used? → Does it create value? → Can standard functionality replace it? → What depends on it? → Is it maintainable and secure? → What does it cost to own and test? → Keep, Refactor, Replace or Retire

This is an independent governance framework, not an official Pronto Software methodology.

1. Is the customisation actually used?

This sounds obvious, but it is an important first filter.

Long-lived ERP environments often contain functionality that survives simply because nobody has had a reason to remove it.

Ask:

• Which users or processes depend on it?
• How frequently is it invoked?
• What outputs does it create?
• What transactions depend on it?
• What would users do if it disappeared?

Where practical, use evidence rather than memory alone.

That evidence might come from transaction history, scheduled activity, report distribution, interface traffic or confirmation from process owners.

A useful principle is:

Historical existence is not evidence of current business value.

However, absence of obvious users does not prove that something is safe to remove. Background processes and integrations can operate with little user visibility.

Unknown usage should trigger investigation rather than retirement.

2. Does it still create material business value?

Once usage is established, return to the business requirement.

Ask:

If we were implementing Pronto Xi today, would we pay to build this again?

Then determine what value it protects.

That value may include:

• revenue;
• margin;
• operational efficiency;
• regulatory compliance;
• financial control;
• customer requirements;
• safety;
• elimination of significant manual work.

A customisation that saves a few clicks for three users deserves a different level of complexity from one that enables a contractual pricing model used for a significant share of revenue.

This is where the CFO should become involved.

The review is not simply an IT exercise.

3. Can standard Pronto Xi functionality now replace it?

ERP functionality changes over time.

Pronto Xi 780, for example, introduced changes across Financials, Payroll & Resources, Inventory, the web client, Asset & Facility Management, Business Intelligence and other areas.

A requirement that once justified development may therefore have a different solution today.

For every material customisation ask:

Can standard functionality in the target release now satisfy the underlying business requirement?

Do not compare features superficially.

Compare the actual business scenario:

requirement → workflow → controls → exceptions → reporting → integrations → financial result

If standard functionality meets the requirement adequately, replacing the custom solution may reduce future complexity.

But “standard” is not automatically better.

If the replacement causes material loss of functionality, control or usability, retaining or refactoring the existing solution may be justified.

4. What is the blast radius if it fails?

This is one of the most important additions to a mature customisation review.

Ask:

If this artefact fails after the upgrade, what stops or becomes incorrect?

Consider a custom pricing routine.

Its blast radius might extend through:

Customer contract → Sales order → Price → Margin → Invoice → EDI → Reporting → General ledger

The code itself might be small.

The business impact is not.

A practical classification might be:

Testing effort should reflect the blast radius, not the number of lines of custom code.

5. What depends on it?

Customisations rarely exist completely in isolation.

Map both upstream and downstream dependencies.

For a material artefact, establish:

Trigger → Inputs → Custom logic → Outputs → Dependent processes → Interfaces → Reports → Financial consequence

Dependencies may include:

• another custom program;
• master data;
• scheduled processes;
• forms;
• interfaces;
• Cognos reports;
• security roles;
• database objects;
• middleware;
• third-party applications.

This is why counting customisations alone is a weak risk metric.

An environment with forty isolated, low-risk extensions may be easier to upgrade than one with five deeply interconnected components.

6. Is it maintainable?

A customisation may remain valuable while its implementation becomes increasingly difficult to support.

Assess at least five things.

Documentation

Could another appropriately skilled Pronto specialist understand what the artefact does and why?

Source ownership

Does the organisation have the current maintainable version of the code or configuration?

Version history

Can the team identify what changed, when and why?

Specialist availability

Does more than one person have the capability to maintain it?

Deployment and recovery

Does the organisation know how the component is deployed and how to restore the previous state if a change fails?

Pronto's RAD environment supports substantial application development using technologies including 4GL, SQL, report generators and debugging facilities.

That capability makes disciplined source and deployment control particularly important for customer-developed functionality.

7. Does it create security or control risk?

A customisation review should not be confined to functionality.

For material artefacts, ask whether they:

• require excessive privileges;
• bypass approval controls;
• expose sensitive data;
• use credentials that are poorly governed;
• circumvent segregation of duties;
• modify financial or operational data outside expected controls;
• depend on obsolete integration methods.

A solution can still “work” while creating unacceptable control risk.

For CFOs, this is particularly relevant where customised logic affects payments, payroll, pricing, journal entries, inventory valuation or access to sensitive information.

8. What does it cost to own for another five years?

Development cost is only the beginning.

The more useful question is:

What is the five-year ownership cost of keeping this customisation?

Include the costs of:

Use the organisation's actual internal and supplier costs rather than generic benchmarks.

Then compare that cost with the business value protected.

A customisation can be expensive and still justified.

The objective is to make that decision consciously.

9. How much testing does it create?

Every critical customer-specific artefact carries a regression-testing obligation.

If custom code controls customer pricing, do not merely test whether the program executes.

Test the whole outcome:

Customer → contract → order → pricing logic → invoice → margin → downstream system → financial posting

Include:

• normal transactions;
• boundary conditions;
• common exceptions;
• interfaces;
• reports;
• financial consequences.

Pronto's implementation approach specifically incorporates testing and business simulations before production use.

The same principle should apply to customisation review during an upgrade:

Test what the business depends on, not merely whether the code runs.

Keep, Refactor, Replace or Retire?

The evidence should lead to one of four decisions.

KEEP

Keep the current solution where:

• the requirement remains important;
• usage is proven;
• material value exists;
• no adequate standard alternative exists;
• maintainability is acceptable;
• security and control risks are acceptable;
• dependencies are understood;
• testing burden is justified.

Example rationale:

Custom contract-pricing logic supports current contractual requirements that cannot be reproduced adequately using evaluated standard functionality. Documentation, source ownership and regression tests are current. Retain.

REFACTOR

This is the category often missing from simplistic customisation reviews.

Refactor where:

• the business requirement remains valid;
• standard functionality does not adequately replace it;
• but the current implementation is unnecessarily fragile, complex or poorly supportable.

Possible reasons include:

• obsolete architecture;
• poorly structured code;
• undocumented dependencies;
• single-person knowledge;
• inadequate error handling;
• difficult deployment;
• unnecessary coupling to other customisations.

The aim is to preserve the valuable requirement while reducing technical debt.

REPLACE

Replace where the underlying requirement remains important but a more supportable solution can now satisfy it.

The alternative might be:

• standard Pronto Xi functionality;
• configuration rather than custom code;
• a supported integration;
• a newer extension mechanism;
• another appropriate supported application.

Replacement should be proven against the original business requirement, not selected merely because it is technically cleaner.

RETIRE

Retire where evidence shows that:

• the business requirement has disappeared;
• usage is negligible;
• the process no longer exists;
• functionality is duplicated;
• users bypass the solution;
• the ownership cost is disproportionate to remaining value.

Dependencies must still be checked.

A customisation that appears unused may quietly feed another process.

The four-way decision table

Treat this as a decision framework, not a formula.

A critical business capability should not be retired because it produces an unfavourable spreadsheet score.

Treat unknown customisations as discovery risk

One of the most dangerous categories is:

“Nobody knows what this does.”

Do not automatically retain it.

Do not automatically remove it.

Classify it as discovery risk.

Before deciding, establish:

• where it executes;
• what triggers it;
• what data it reads or changes;
• who or what uses its output;
• what systems depend on it;
• what happens when it fails.

Then determine whether to:

Document → Keep / Refactor / Replace / Retire

The first objective is to remove uncertainty.

Who should make the decision?

Customisation disposition should not belong exclusively to IT or the developer.

The developer can explain the technical implications.

The organisation must decide whether the capability is worth owning.

What evidence should be retained?

For every material customisation that survives the review, retain enough evidence to explain:

Why it exists → who owns it → how it works → what depends on it → where it is maintained → how it is tested → why the organisation chose its disposition

This matters for future upgrades.

Without decision history, organisations repeatedly spend money rediscovering why historical customisations exist.

A maintained customisation register turns that knowledge into an organisational asset.

Pronto Xi customisation review checklist

Before approving the upgrade, confirm that each material customer-specific artefact has been reviewed for the following:

• Current usage is known.
• A business owner exists.
• The underlying requirement remains valid.
• Business criticality and failure impact are understood.
• Standard functionality in the target environment has been considered.
• Upstream and downstream dependencies are mapped.
• Current code or configuration is accessible.
• Version/deployment information exists where applicable.
• More than one person can support critical functionality, or backup support is available.
• Security and control implications have been reviewed.
• Five-year ownership cost is understood sufficiently for a rational decision.
• Required regression tests are defined.
• A documented decision has been made: Keep, Refactor, Replace or Retire.

Unknown items should enter discovery before they are carried forward.

Need Pronto Xi capability for a customisation or upgrade review?

If a review exposes gaps in Pronto functional, technical, 4GL/RAD, integration, BA or testing capability, SAAPRO can help assess the availability of suitable specialists in the Australian Pronto Xi market before skills become an upgrade constraint.

Disclosure: SAAPRO is an independent Pronto Xi recruitment specialist and is not Pronto Software or an ERP implementation vendor.

Product-specific statements above are based on current publicly available Pronto Software documentation. The usage → value → alternative → dependency → maintainability/security → five-year cost → disposition framework is an independent governance framework developed for this article and is not presented as an official Pronto Software methodology.

Whether a particular artefact should be kept, refactored, replaced or retired depends on the organisation's actual Pronto Xi environment, business requirements, source/configuration, dependencies and target release.