ETRM implementations and upgrades often come with a familiar challenge: figuring out which business processes need to be preserved and which ones need a fresh look.

When teams are asked to adapt to a new system, “We’re unique” is a common response. And sometimes, they’re right. Commodity trading businesses have specific requirements. But not every process that feels essential today needs to be rebuilt in a new system. Some are simply habits that have gone unquestioned for years.

The problem is that customizing a system to match every existing process can add development costs, complicate future upgrades and create ongoing maintenance work. Instead of improving how the business operates, you can end up carrying old inefficiencies into a new platform.

At IGNITE, we recognize that every trading business has its own requirements, and customization has a role to play when standard functionality isn’t enough. But it’s just as important to understand what a system can already do before investing in custom development. Often, configuration or a change in process can deliver the same result with less complexity.

If you’re evaluating an ETRM system, working through an implementation or planning an upgrade, here are seven questions to ask before committing to a change.

First, understand the difference between configuration and customization

Configuration and customization often get used interchangeably during ETRM projects, but they aren’t the same thing. Understanding the difference can help your team make better decisions before development work begins.

Configuration involves using the settings and tools already available within the platform. This might include setting up commodities, trading books, pricing formulas, approval workflows, user permissions, reports and integrations. You’re adapting the system to your business using functionality the vendor already supports.

Customization involves extending or changing the product itself. That could mean adding new code, creating bespoke screens, developing specialized business logic or introducing data structures that aren’t part of the standard platform.

Customization has its place, but it also creates additional responsibilities. Someone needs to document the changes, test them, maintain them and make sure they continue working as the core software evolves.

A useful question to ask is what happens when the system is upgraded. Configuration generally relies on functionality already supported and maintained within the platform, while customization introduces additional functionality or logic that may require separate development, testing, and ongoing maintenance. The precise distinction depends on the platform and the nature of the change. 

Modern ETRM platforms, particularly cloud-based SaaS solutions, often offer more configuration options than older systems. Before assuming a requirement needs custom development, it’s worth finding out what the platform can already do.

At IGNITE, we emphasize flexibility and configuration as important parts of our platform’s design. Our goal is to help trading businesses accommodate their specific requirements using existing platform capabilities wherever possible, while supporting additional development when there is a genuine business need.

7 questions to ask before changing your ETRM

1. What business problem are we trying to solve?

Before discussing a feature or requesting development work, make sure everyone understands the problem behind it.

For example, a team might request a custom trade confirmation screen. But what is driving that request? Are counterparties disputing confirmations because pricing terms aren’t clear? Is important information missing? Or does the team simply prefer the layout of its existing system?

Those situations call for different solutions.

Try to describe the issue in terms of its business impact. It might be a settlement error that keeps occurring, a risk exposure that isn’t visible to the right people, a control gap or a regulatory requirement that needs to be addressed.

If the conversation stays focused on recreating a particular screen or spreadsheet, you may be solving the wrong problem. Once the underlying issue is clear, it’s much easier to evaluate whether configuration, customization or a process change makes the most sense.

2. Is this a genuine business requirement or simply the way we’ve always worked?

This is worth exploring before approving any customization.

When businesses replace an ETRM system, teams often request familiar reports, approval steps and workflows because that’s what they’re used to. Some of those processes are essential. Others may have developed around limitations in an older system or circumstances that no longer apply.

Consider a manual reconciliation step that was introduced years ago because data had to be entered into two separate systems. If the new platform can exchange that data automatically, does the manual step still serve a purpose?

The same question applies to approval workflows, report layouts and spreadsheets maintained by individual team members.

Ask who introduced the process, what problem it was intended to solve and whether that problem still exists. It can also help to ask what would happen if the process were removed altogether.

If nobody can explain why a particular step is necessary beyond saying it’s always been done that way, take a closer look before turning it into a development requirement.

An implementation is a good opportunity to review these processes because the business is already preparing to change how it operates. Making those decisions early can prevent unnecessary development work later.

3. Can the requirement be handled through configuration?

Once you understand the business need, the next step is to find out whether the platform already supports it.

Depending on the system, configuration options might include pricing rules, workflow conditions, user permissions, reporting tools, approval thresholds or integration settings. A requirement that initially sounds complicated may be straightforward once someone familiar with the platform reviews it.

This is where the experience of your implementation partner matters.

A good vendor team should understand your requirements and explain the available options before recommending custom development. They should be able to demonstrate how a standard feature could address the issue, including any limitations or trade-offs.

It’s also worth asking how other trading businesses handle similar requirements. If a process is common across the industry, there’s a reasonable chance the platform already has a way to support it.

That doesn’t mean every standard feature will meet your needs. It simply means customization shouldn’t be the starting point before the existing functionality has been explored.

4. What will this change cost us over the next few years?

The initial development estimate only tells part of the story. Before approving a customization, look at the total cost of ownership: the build itself plus the testing, documentation, support and upgrade work it will need for as long as it stays in place.

Ask the vendor to explain the expected costs beyond the initial build. Find out how the change will be supported, who will maintain it and what will happen when the platform is upgraded.

A customization might still be the right investment. The important thing is to understand the commitment you’re making rather than treating it as a one-time expense.

5. Which other teams and systems will this affect?

A change that looks simple from one team’s perspective can have consequences elsewhere in the business.

For example, adding a custom field to a trade record might help the trading desk capture additional information. But that field could also need to appear in risk reports, trade confirmations, invoices, settlement processes and accounting systems.

If those downstream requirements aren’t considered early, the business could end up with inconsistent data or additional manual work.

Before approving a change, bring in the people who will use the information or depend on the affected process. That might include trading, risk management, operations, settlements, finance and IT.

It’s also important to consider integrations with external platforms, such as market data providers, treasury systems and your ERP. A change within the ETRM system may require updates elsewhere to keep information flowing correctly.

Getting the right people involved early helps identify these dependencies before development begins. It also gives the project team a clearer picture of the actual scope, rather than discovering additional requirements during testing.

6. Does the business value justify the additional complexity?

Not every customization delivers the same return.

Some address requirements that are essential to the business, such as jurisdiction-specific regulatory reporting, specialized contract structures or calculations that directly affect trading margins. Others might save a small amount of time for one person while creating additional maintenance work for years.

It helps to evaluate the expected benefit alongside the full cost of implementation and ownership.

Consider questions such as:

• Will the change reduce operating costs or prevent recurring errors?
• Does it improve risk visibility or strengthen an important control?
• Is it necessary to meet a regulatory or contractual requirement?
• How much development, testing and ongoing maintenance will it require?
• Will it affect multiple teams, reports or integrations?
• Could the same outcome be achieved through configuration or a simpler process?

A change that delivers significant commercial value and has limited downstream impact may be worth pursuing. One that offers little benefit but introduces substantial complexity deserves more scrutiny.

Some decisions will be straightforward. Others will require input from different parts of the business, especially when the benefits are difficult to quantify. In those cases, documenting the expected outcome and agreeing on how success will be measured can help the team make a more informed decision.

7. Could a process change or better training solve the problem?

Sometimes the best solution doesn’t involve changing the software at all.

Users might request a new report because they don’t know how to access an existing one. A team might want to recreate a familiar approval workflow because it’s uncomfortable with a new process. Or employees may continue using spreadsheets because they haven’t been shown how the new system handles the same information.

In these situations, custom development won’t necessarily address the underlying issue.

Before moving forward, check whether the requested functionality already exists and whether users understand how to use it. If the new system changes an established process, consider whether updated procedures, clearer guidance or additional training would help.

This doesn’t mean every request should be answered with more training. If the platform genuinely can’t support an important business requirement, the project team needs to address that gap.

The point is to distinguish between a system limitation and an adoption problem. That distinction can save time, reduce unnecessary development and help employees get more value from the technology they already have.

The long-term costs of too much customization

Even when individual customizations seem reasonable, their combined impact can become difficult to manage. The costs often become more apparent after implementation, when the system is in daily use and the business needs to keep it running while making further changes.

Here are five areas worth considering.

Maintenance

Custom code needs ongoing support. Someone must understand how it works, keep the documentation current and troubleshoot problems when they arise. If the people who built the customization leave, the business may have to spend additional time and money bringing someone else up to speed.

Upgrades

Upgrades can become more complicated when custom development affects how the core platform operates. Changes need to be reviewed and tested to make sure existing functionality still works, and some customizations may need to be adjusted or rebuilt.

If that work becomes too expensive or disruptive, businesses may delay upgrades. Over time, they risk falling behind on new features, improvements and supported software versions.

Our guide to commodity trading software and what to look for in 2026 and 2027 explores over-customization as one of the risks businesses should consider when evaluating a platform.

Scalability

A customization built around one commodity, entity or trading book may not work as well when the business expands. Adding new requirements can lead to further development instead of allowing the company to use existing configuration options.

That can make growth more complicated than it needs to be.

Integrations

Custom fields, calculations and data structures can affect connections between the ETRM system and other business applications. Each integration needs to be mapped, tested and maintained, and changes in one system can create problems elsewhere.

The more bespoke functionality involved, the more carefully those dependencies need to be managed.

Support and troubleshooting

When something goes wrong, teams need to identify whether the problem sits within the core platform, a customization or an integration between systems. A heavily customized environment can make that investigation more time-consuming, particularly when documentation is incomplete.

For trading and risk teams that depend on accurate, timely information, delays in resolving issues can have operational consequences.

The platform’s delivery model also matters. With a cloud-based SaaS solution such as IGNITE’s, built on Microsoft Azure, the standard platform can evolve through centrally delivered updates. Keeping custom development to what the business genuinely needs can make it easier to benefit from those improvements.

You can learn more about how the IGNITE platform approaches configuration, integration and reporting.

How to recognize a process that needs to change

Some established processes exist for important commercial, operational or regulatory reasons. Others have simply carried over from an older way of working.

A process deserves a closer look if:

• It was introduced to work around a limitation in the system you’re replacing.
• Nobody can explain why it’s necessary or who originally requested it.
• It requires employees to re-enter information that the new platform already holds.
• It relies on a spreadsheet that one person has to maintain manually.
• It adds a manual check for a risk the new system can already control.
• It creates more work than a comparable process would in a modern trading environment.

One sign alone doesn’t necessarily mean a process should be removed. But if several apply, talk to the people who use it and see whether the new platform offers a simpler way to get there before asking the vendor to recreate it.

Change management needs to be part of the plan

Choosing the right technology is only one part of an ETRM implementation. When teams are reluctant to give up familiar screens, reports and approval steps, customization can seem like the easiest answer, but recreating every existing process rarely gets the most out of the investment. A few practical steps can make the transition easier.

• Establish clear approval criteria. Give a steering committee or designated project owner responsibility for reviewing customization requests against agreed business requirements, costs and risks.
• Involve users early. Ask the people who will use the system what they need to accomplish. Their input can help identify genuine requirements and build support for changes to existing processes.
• Explain the reasons behind decisions. If a familiar report is being replaced by a standard report that provides better exposure information, show users how the new option meets their needs rather than simply rejecting the request.
• Train employees on the process as well as the software. Users need to understand how their responsibilities may change, not just where to find features and buttons.
• Review feedback after go-live. Once employees have spent time using the system, some initial customization requests may no longer be necessary. Others may reveal gaps that weren’t apparent during implementation. Both are useful findings.

These steps won’t eliminate every disagreement, but they give the team a consistent way to evaluate requests and explain its decisions.

The businesses that get the most from their ETRM investments aren’t necessarily those with the fewest customizations. They’re the ones that understand where their requirements are genuinely different and make deliberate decisions about how to support them.

Configure where possible, customize when necessary

An ETRM platform needs enough flexibility to support the way a commodity trading business operates. The challenge is finding that flexibility without creating unnecessary development and maintenance work.

Before approving a change, make sure the team understands the business problem, has explored the platform’s existing capabilities and has considered the long-term implications. If the requirement can be met through configuration, there’s often little reason to build a custom solution. If the process itself is outdated, changing the process may be the better option.

And when customization is necessary, it should be based on a clear business need, with the costs and responsibilities understood from the start.

At IGNITE, we believe a successful CTRM implementation should balance flexibility with long-term maintainability. Our configurable, multi-commodity platform is designed to accommodate complex trading requirements while helping businesses avoid unnecessary development and complexity.

Whether you’re evaluating a new CTRM platform or reviewing your existing processes, our team would welcome the opportunity to discuss your requirements and explore the most practical approach.

Talk to our team about your ETRM implementation or book a demo to see how IGNITE can support your trading workflows.

Frequently asked questions

What is the difference between configuration and customization in an ETRM system?

Configuration uses the settings, rules and tools already available within the platform. Customization adds or changes functionality through bespoke code or logic. Configuration is generally easier to maintain through upgrades, while custom development may require additional testing and ongoing support.

Is customizing a CTRM system always a bad idea?

No. Customization can be valuable when a business has a genuine commercial, operational or regulatory requirement that the standard platform cannot meet. The key is to weigh the benefits against the development costs, maintenance requirements and potential impact on future upgrades.

Why do ETRM implementations go over budget?

There can be several reasons, including unclear requirements, underestimated data migration, integration challenges and expanding project scope. Recreating existing processes without reviewing whether they’re still necessary can also add avoidable development work and testing costs.

How should we decide which ETRM customization requests to approve?

Start by identifying the business problem, then check whether the requirement is essential or simply reflects an existing habit. Explore configuration options, estimate the long-term costs, identify affected teams and systems, and consider whether a process change or training could achieve the same result. Approve customization when the business benefits justify the additional complexity.