Wednesday, 4 November 2026

Strategy for Your Legacy Customizations

This is part Two of a Three-Part Series on dispelling the myths behind moving to Fusion SaaS and strategies for success. 

In part one, I looked at the common myths around why moving to Fusion SaaS is just too hard. Once you start to consider the move, you can deploy strategies to make your project successful. In this blog. We’ll look at your customizations, and in the final part how to approach the other parts of your implementation.

 

Customizations

Let’s look very quickly at what we mean by customizations. Oracle talks about CEMLIs: Configurations, Extensions, Modifications, Localisations, and Integrations .

 

Catalogue 

You need understand what you've got. Do you have a good catalogue of those CEMLIs, or are you just aware that there are lots of them? Regardless of whether you have any thoughts about moving, make sure your catalogue is up to date. Then youcan start to declutter, either today to improve your Apps Unlimited environment or as preparation for a move down the line.


 

Declutter

Let’s explore some examples. Many customizations are owned by the DBA, who wants to make sure they are not caught out by an index or tablespace violation. Maintenance-type customizations are simply not necessary in Fusion, as maintenance is the responsibility of Oracle. There may be alerts for other things that can be done in a different way within Fusion and are very simple to set up.

Often, I see that customized functionality is available in Fusion and was actually available in Apps Unlimited, but not at the time it was written. It has since been superseded by new functionality that the organisation has not moved forward with. I have seen, in more than one organisation, reports that are run just to check that the system is correct, especially in finance. That is just a confidence issue from when the system was first implemented, so it is not necessary going forward.

Customization holding extra data in configured fields (Descriptive FlexFields, DFFs) is supported and can easily be replicated within SaaS and then available in all your reports.

Assessment

With many organistions we have run a system health check , help them to catalogue CEMLIs if they don't have a good catalogue, and there is software that can help us do that. Or we take their catalogue assess each one of those. 

Is it needed? Can it be replaced? Is it still necessary for the organisation? Or is it done a different way in Fusion? Some of that work can be done in preparation

 

Reporting Strategy

There will be reports. All organisations have specific reporting requirements, and many of those are not out of the box. You must have a reporting strategy: how are you going to get the data you need, and what skills do people need? If you are using Finance, which of your roles will be using Smart View, where they are looking just at ledger data, or have access to other reporting tools? Not all of your organisation will need reports; what they need is data, and the concept of pushing data to users through dashboards is a much easier way for that data to be on hand. 

Extend

If your customization is a whole new process and not a process covered by Fusion functionality, then you will need it going forward. But now is the time to look at that customization and see if you can extract it from within your Apps Unlimited solution, make it standalone, perhaps in a more modern technology such as APEX or VBCS, and run it in co-existence. That means there will be much less for you to do when you move to Fusion.

Do Not Rewrite Your Existing System in Fusion

The very first Fusion implementation I worked on had this phase on the project room wall: “The new system will do everything the old system does, but not necessarily in the same way.” You will fail on day one if you insist it must be exactly the same.


I once had a customer in the telecoms industry who told me they had over 1,100 customizations. When we did their roadmap to Fusion, there were fewer than a dozen that had to be replicated as extensions. That is not necessarily the typical number, but it is typical in showing that you don't need all of your customizations going forward.

Once you understand what is needed in Fusion, you can assess the size of the task, categorising each item as small, medium, or large, and identifying the technology or approach needed for each one. When you have all of that information, you then have a roadmap of how to eat the elephant bit by bit.

It is also important to talk to the business. Do they need to make changes to those customizations? A move may be a great opportunity to change your chart of accounts to better reflect your organisation today.

 

Legacy customisations do not have to stand in the way of Fusion. By cataloguing and assessing your CEMLIs, removing what is obsolete or already covered by standard functionality, defining a clear reporting strategy, and extending only where there is a genuine business need, you can reduce complexity and create a practical roadmap, without simply recreating your old system in the cloud. But customisations are only one part of a successful move. Read the final blog in the series to discover how to navigate the wider implementation challenges, from data cleansing, migration and archiving to integration, change management, quarterly updates, partner selection and the role AI can play in delivering lasting value.


Part Three will look at some strategies for success in the move.

No comments: