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 -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 –Practically, keeping those sunset systems is highly unadvisable for the following reasons: 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 –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 -
Latest News
Creating quality content that help to improve your business is at the heart of what EV is. We aim provide a comprehensive platform that support the growth of young and ambitious entrepreneurs through unique insights and valuable networks
We respect your privacy. The email address you provide will be used solely for subscription purposes and will not be stored or shared.
Subscribe Now