Data migration at the press of a button? As if! How to tackle the challenge properly

But let us start at the beginning. When do housing companies actually find themselves in the position of needing to move or change data en masse or to switch systems? We can look at various scenarios to answer this question: Existing IT systems have expired, need to be updated or the company wants to harmonise them (e.g. to support new terminal devices or because basic technology is no longer supported), the portfolio has changed in the scope of mergers and acquisitions, or there have been current changes in the law. Whatever the reason for a migration project, existing data always needs to be processed in some way, and a housing company’s most vulnerable area is thus affected. External intervention in existing processes always provokes a certain amount of reservation and fear of change, and the same applies to migrations. They are an organisational challenge for companies, whereby the impact on operations must be kept to a minimum. It is therefore important that service providers are receptive and open to the customers’ expectations and requirements and that customers accept that the migration will be a challenge.  

Application cases for migration  

PROMOS has performed many data migration projects during its history, including with the all-in-one industry solution PROMOS.GT. There are three basic application cases for data migration:  

1. Migration in order to implement SAP^®. This involves implementation of SAP^® ERP/RE-FX as a target system from a non-SAP^® system. A current example on the market for ERP systems in the housing industry is the topic of GES. The decision to phase out the system in the medium term has clearly stirred the market, and this applies to users as well as software providers. Furthermore, it involves the special case of switching from a third-party SAP^® system to SAP^®. At first glance, a migration within SAP probably seems quite easy, but every system has customer-specific modifications. In other words, every system speaks its own dialect and SAP does not provide migration support as standard.  

2. Reassignment, for example to move real estate portfolios within the SAP^® system. Imagine a housing company that has a similar structure to a corporate group and various subsidiaries. If part of the real estate portfolio needs to be rearranged, for example because of a sale within the Group network, the data does not leave the system but is transferred to another company code. As SAP did not provide much support in the past for migrating this data, our customers found this scenario extremely difficult to implement. Other tools, such as the Object Retirement and Transfer Tool (OR&TT), are used as aids for the data transfer. This allows us to adapt to the increasingly dynamic situation in real estate portfolios.  

3. Migration to implement mass changes in inventory data; for example, so that employees do not have to enter new bank details or a new measurement type manually for a portfolio of 50,000 apartments.  

PROMOS methodology and procedure  

PROMOS’ data migration expertise is distinguished above all by a combination of methodology, long-standing project experience, and additional services relating to data migration. When migrating application data, the key objective is to provide a new set of data that can be used immediately in live systems. This means taking data from a legacy system, adapting it appropriately so that it is understood in the target system and retains the same meaning, and then importing it into the new system. For this data preparation methodology, PROMOS uses the ETL model and the three stages extraction, transformation and loading, which is familiar from data warehouse operation.  

When it comes to the procedure in the migration process, PROMOS works in line with the level-by-level planning recommended by SAP^®, which is generally valid for all migration projects. There are four stages to this procedural plan (figure 1).

PROMOS has successfully completed countless projects with this systematic, tried-and-tested procedure. The use of standard SAP^® interfaces ensures error-free, audit-proof migration and top-quality results. Primarily core data is migrated automatically with the aid of SAP^® programs. In the scope of extended migrations, further customer-specific fields can generally also be included in the data transfer using various PROMOS programming interfaces, if required. A test migration ensures that the data quality and functionality are checked, especially in Customising, even before the customer performs final quality tests under supervision. Generally speaking, with migration projects, it is often only possible to identify optimisation potential for smooth and efficient migration in hindsight. However, in such cases, PROMOS can draw on many years of expertise and best practices in all three of the migration application cases described above – and our experts pass on this valuable experience to our customers. Moreover, in addition to the tried-and-tested project procedure, customers who see themselves as hesitant and risk-averse benefit above all from the short coordination channels within PROMOS resulting from the efficient project structure.  

The PROMOS data migration solution is rounded off by additional services. One example is the provision of and training for the SAP function Legacy System Migration Workbench (LSMW), which can be used to reuse certain steps or components of a previously completed migration independently. The LSMW is particularly beneficial for customers with dynamic real estate portfolios; that is, companies that repeatedly purchase inventories.

6 Data migration pitfalls  

Nevertheless, data migration is always a challenge in practice, not least because customers often underestimate the work involved. To help you recognise and avoid potential pitfalls, in the following, we present the key factors that cause migration projects to fail.  

The myth of “migration at the press of a button”: Migrations, as they are described here in the application cases, are always unique. This means that a separate project is required for each migration, particularly if the system has been tailored to customer-specific requirements. Otherwise, we are talking about interfaces that regularly transfer data, and these are two entirely different requirements. Customers must be aware of this fact before they plan a migration, as the two solutions involve different organisational effort and time expenditure. In conclusion, a migration can never be implemented at the press of a button.  

The neglected topic of data cleansing: Data can also become obsolete and exceed its “best before” date. When legacy systems need to be replaced and the data transferred to a new system, “dead” data often resurfaces that had previously been successfully filtered out of reports in the legacy system. PROMOS has found a data cleansing project in the legacy system to be very useful for our customers, as it provided security regarding their data inventory and allowed them to eliminate errors and invalid values.  

Postponed is not abandoned: In practice, customers perform extensive data cleansing prior to extraction in just one in ten cases. As a result, the necessary processing work is shifted to later phases, when stress is already at its peak and nerves are frayed. Data cleansing in the legacy system at an early stage is therefore much less stressful for both project partners, as the customer avoids unnecessary misunderstandings and additional costs.  

Planning bottlenecks: In many cases, migration is part of a functional enhancement project and is the final step in the implementation plan. The data migration also needs to be scheduled relatively near to the actual live rollout, leaving only a very short time window for subsequent maintenance and other activities. However, caution is required, because all delays from preceding project activities have an impact on the data migration in particular. Anything that has not yet been completed can usually no longer be resolved before the go-live date. In the worst case scenario, customers are at risk of follow-up errors in the data migration because individual configurations in basic elements are missing.  

Trade-off for scheduling: As the success of a project depends largely on the users being able to work with the new system in full from the first day after it goes live, the transition needs to be as seamless and smooth as possible, with guaranteed full functionality and top-quality data. But, like they say, “trust is good, control is better”. With so much diverse data involved, checking is essential and the tests required for this also take up time. This needs to be planned before the actual go-live date, possibly even with additional time for troubleshooting. In addition, preliminary processes and restrictions need to be taken into account, such as the conclusion of periodic activities like debit positions, payment runs and payroll accounting, before the conversion. As a result of the interaction between these various required activities, the data migration moves further and further away from the original deadline. This means that the transition to actually importing the data into the live systems must be put in the calendar at an early stage based on the business requirements, risk tolerance and customer expectations.  

Test migration causes headaches: However, test migrations also mean that ongoing changes may occur during the period between data extraction and data provision; for example, new lease-outs or terminations that were previously maintained in the legacy system only. As a result, the data in the new system is already obsolete before the system is even launched. In this case, “duplicate data maintenance” is required to synchronise the two systems, which is sometimes very inconvenient for the customer. This is why it is particularly important to choose the right time for the migration.  

How to tackle the challenge of data migration properly  

Based on these pitfalls, you can derive methods for transferring complex and extensive data inventories to the relevant target system in a resource-friendly manner and with a high level of data quality. Make use of our tips for successful, stress-free migration:

• Take into account the complexity of the project – there is no such thing as data migration at the press of a button!
• Do not rush the project. Find a suitable time window for implementation and allow a realistic period of time.
• Set up a perfect team with sufficient project members on both sides.
• Use short coordination channels to maintain a good flow of communication.
• Preparation for the migration is key, and this includes cleansing the data in a preliminary project before the extraction. This significantly reduces errors and the overall workload.
• Use test migrations. You should begin testing the import procedure and target functionality at an early stage of the project.
• And, as is so often the case in life, the success of a migration project also depends on choosing the right partner for the job.