We’re in the move to S/4HANA
The evolution of IT systems is an inevitable element in a corporate environment. It means that from time to time, some corporate applications need migration to a new one – the same is the case with SAP ERP systems. For the past 8 years, SAP has been promoting the replacement of its flagship SAP ECC solution with the SAP S/4HANA solution. In this case, this migration encompasses the implementation of different software (it is not just an upgrade), the adoption of a different database (if you were not already using HANA DB), and a different database model along with a full migration project.
Different migration options
The current migration projects are more complex than they used to be in the old days. Today, you can rely on pre-configured solutions such as the SAP Migration Cockpit or Selective Data Transition (SDT) solutions. You may also go for a more technical solution called the Brownfield migration. This approach carries over as many custom components as possible from the source system and minimizes the initial re-engineering efforts.
S/4HANA migration provides no traceability back to the original ERP system.
While the solutions are handy for migration, all these solutions come with a common pitfall – there is no migration traceability. That means it is not possible to prove that all data was migrated, nor that it had remained unchanged (it’s the original data) or un-filtered (we have all data). In other words, if you cannot prove that the data has remained complete and unchanged, then the original legacy system must be kept, ensuring it meets all the compliance requirements. All in all, this is fine – we don’t need migration traceability; however, what we certainly want is an efficient new system.
It is imperative to ensure that your new system does not carry over historical data from the past; the new system should support improved business processes to answer the marketplace demands. The migration target is to build a great new system for managing future business processes in an improved way, providing better customer service with increased profits.
So, we could keep sunset (legacy) systems…
Now that we all agree the new system is not designed as a legacy archive, we must bear in mind that historical data is still a key source of information in many ways. Therefore, there is a strong need to retain access to legacy data –
- to respond to audit or tax requests
- in case previous data and documents need accessing.
From time to time, you must possess data you can trust to show in court if required.
So sunsetting a legacy system (in a read-only status) is a plausible option, but it doesn’t come risk-free. These are some of the challenges that come along, namely –
- Running legacy systems is costly.
- They increase the “technical debt.”
Practically, keeping those sunset systems is highly unadvisable for the following reasons:
- Common usages, like Virtual Machines, are becoming far too vulnerable to frequent cyberattacks.
- Since GDPR came into force in 2018, most countries and several US States have been pushing for heavy financial and reputational penalties because of breaking data privacy laws. Legacy systems usually do not enforce data privacy requirements; it is difficult to handle such obligations in these historic systems simply because they were not originally designed with that logic.
In the past, it could have been acceptable to pay for the maintenance of the legacy systems database or even to bear the burden of maintaining a Virtual Machine. Nevertheless, today keeping a legacy system alive requires a different budget.
Securing a system from day-to-day vulnerabilities encompasses an array of obligations – taking care of servers, applications, storage, networks, operating systems, data, and run time for most classical legacy systems. It means acting, at each level, on security, updates, authorizations, help desks, management, training, and third-party contracts.
Or we manage to decommission legacy systems!
Hence, a new type of application is emerging: “legacy system applications”. Such applications allow organizations to take one step forward, moving from system sunsetting to system decommissioning.
Legacy applications can deal with legacy reports, master transactional data, generated or linked documents (such as invoices, delivery documents, emails, etc.), and archives (SAP systems generate loads of SAP data archive files named ADK files) with utmost detail and traceability. Important to note that system documentation must be kept for audit purposes. The good news is that legacy systems are becoming a growing concern, and hence there are several options available in the market to deal with them.
Best practices to sunset systems in S/4HANA migration
Firstly, when migrating to S/4HANA (or when migrating any application), decide the future of your sunset systems like –
- If you want to consider deleting the system (I will not advise this for ERP systems).
- If you want to keep the system, considering you are willing to pay a high price.
- Sit on the fence – postpone the deletion of the system while storing it in a temporary Virtual Machine.
- Create a tax archive for legal purposes (extracting data, reports, documents, and documentation in a controlled environment).
- Or last, but not least, go for the implementation of an Enterprise Legacy System Application (ELSA)
Secondly, define a timeframe and a blueprint. I strongly advise dealing with the legacy systems as a separate project from the migration project.
Finally, if you decide to initiate a decommissioning project, you may run it in parallel with the migration project and reap the benefits of having access to legacy information. It is highly reassuring and positively impacts the more innovative and efficient IT system.
The final word
The final advice is to conduct a robust selection process when choosing the legacy system application solution, as this application will become the global future hub for all the running applications within the company.
Here are some essential features you may want to find in a legacy application and the corresponding IT supplier –
- Ability to support tax & audit demands.
- Capacity to quickly apply evolving data privacy regulations.
- Ability to run the system safely and securely.
- To stay updated with the latest security updates & prevent any vulnerabilities.
- A user-friendly interface, ideally training-free for new employees to access historical information on old applications.
