No Drama Data Migration
With Mergers, Acquisitions and Divestments at record levels, the speed and effectiveness of data migration has come under the spotlight. Every step of this data migration process raises concerns, especially in spin-off or divestment deals where just one part of the business is moving ownership.
What happens if confidential information is accessed by the wrong people? If supplier requests cannot be processed? If individuals with the newly acquired operation have limited access to vital information and therefore do not feel part of the core buyer’s business? The implications are widespread – from safeguarding Intellectual Property, to staff morale, operational efficiency, even potential breach of financial regulation for listed companies.
With traditional models for data migration recognised to be high risk, time consuming and can potentially derail the deal, Don Valentine, Commercial Director at Absoft explains the need for a different approach – one that not only de-risks the process but adds value by reducing the time to migrate and delivering fast access to high quality, transaction level data.
Recording Breaking
2021 shattered Merger & Acquisition (M&A) records – with M&A volume hitting over $5.8 trillion globally. In addition to whole company acquisitions, 2021 witnessed announcements of numerous high-profile deals, from divestments to spin-offs and separations. But M&A performance history is far from consistent. While successful mergers realise synergies, create cost savings and boost revenues, far too many are derailed by cultural clashes, a lack of understanding and, crucially, an inability to rapidly combine the data, systems and processes of the merged operations.
The costs can be very significant, yet many companies still fail to undertake the data due diligence required to safeguard the M&A objective. Finding, storing and migrating valuable data is key, before, during, and post M&A activity. Individuals need access to data during the due diligence process; they need to migrate data to the core business to minimise IT costs while also ensuring the acquired operation continues to operate seamlessly. And the seller needs to be 100% confident that only data pertinent to the deal is ever visible to the acquiring organisation.
Far too often, however, the data migration process adds costs, compromises data confidentiality and places significant demands on both IT and business across both organisations.
Data Objectives
Both buyer and seller have some common data migration goals. No one wants a long-drawn-out project that consumes valuable resources. Everyone wants to conclude the deal in the prescribed time. Indeed, completion of the IT integration will be part of the Sales & Purchase Agreement (SPA) and delays could have market facing implications. Companies are justifiably wary of IT-related disruption, especially any downtime to essential systems that could compromise asset safety, production or efficiency; and those in the business do not want to be dragged away from core operations to become embroiled in data quality checking exercises.
At the same time, however, there are differences in data needs that can create conflict. While the seller wants to get the deal done and move on to the next line in the corporate agenda, the process is not that simple. How can the buyer achieve the essential due diligence while meeting the seller’s need to safeguard non-deal related data, such as HR, financial history and sensitive commercial information? A seller’s CIO will not want the buying company’s IT staff in its network, despite acknowledging the buyer needs to test the solution. Nor will there be any willingness to move the seller’s IT staff from core strategic activity to manage this process.
For the buyer it is vital to get access to systems. It is essential to capture vital historic data, from stock movement to asset maintenance history. The CIO needs early access to the new system, to provide confidence in the ability to operate effectively after the transition – any concerns regarding data quality or system obsolescence need to be flagged and addressed early in the process. The buyer is also wary of side-lining key operations people by asking them to undertake testing, training and data assurance.
While both organisations share a common overarching goal, the underlying differences in attitudes, needs and expectations can create serious friction and potentially derail the data assurance process, extend the SPA, even compromise the deal.
Risky Migration
To date processes for managing finding, storing and managing data pre, during and post M&A activity have focused on the needs of the selling company. The seller provided an extract of the SAP system holding the data relevant to the agreed assets and shared that with the buyer. The buyer then had to create configuration and software to receive the data; then transform the data, and then application data migration to provide operational support for key functions such as supplier management.
This approach is fraught with risk. Not only is the buyer left blind to data issues until far too late but the entire process is time consuming. It also typically includes only master data, not the transactional history required, due to the serious challenges and complexity associated with mimicking the chronology of transactional data loading. Data loss, errors and mis-mapping are commonplace – yet only discovered far too late in the process, generally after the M&A has been completed, leaving the buyer’s IT team to wrestle with inaccuracy and system obsolescence.
More recently, different approaches have been embraced, including ‘behind the firewall’ and ‘copy/raze’. The former has addressed some of the concerns by offering the buyer access to the technical core through a temporary separated network that houses the in-progress build of the buyer’s systems. While this avoids the need to let the buyer into the seller’s data and reduces the migration process as well as minimising errors, testing, training and data assurance, it is flawed. It still requires the build of extract and load programs and also uses only master data for the reasons stated above. It doesn’t address downtime concerns because testing and data assurance is still required. And it still demands the involvement of IT resources in non-strategic work. Fundamentally, this approach is still a risk to the SPA timeframe – and therefore does not meet the needs of buyer or seller.
The ‘copy/raze’ approach has the benefit of providing transactional data. The seller creates an entire copy and then deletes all data relating to assets not being transferred before transferring to the buyer. However, this model requires an entire portfolio of delete programmes which need to be tested – a process that demands business input. Early visibility of the entire data resources ensures any problems that could affect the SPA can be flagged but the demands on the business are also significant – and resented.
De-risking Migration
A different approach is urgently required. The key is to take the process into an independent location. Under agreement between buyer, seller and data migration expert, the seller provides the entire technical core which is then subjected to a dedicated extract utility. Configuration is based on the agreed key deal assets, ensuring the extraction utility automatically undertakes SAP table downloads of only the data related to these assets – removing any risks associated with inappropriate data access.
The process is quicker and delivers better quality assurance. Alternatively, the ‘copy/raze’ approach can be improved by placing the entire SAP system copy into escrow – essentially a demilitarised zone (DMZ) in the cloud – on behalf of both parties. A delete utility is then used to eradicate any data not related to the deal assets – with the data then verified by the seller before the buyer has any access. Once confirmed, the buyer gains access to test the new SAP system prior to migration.
These models can be used separately and in tandem, providing a data migration solution with no disruption and downtime reduced from weeks to a weekend. The resultant SAP solution can be optimally configured as part of the process, which often results in a reduction in SAP footprint, with the attendant cost benefits. Critically, because the buyer gains early access to the transaction history, there is no need for extensions for the SPA – while the seller can be totally confident that only the relevant data pertaining to the deal is ever visible to the buyer.
Conclusion
By embracing a different approach to data migration, organisations can not only assure data integrity and minimise the downtime associated with data migration but also reduce the entire timescale. By cutting the data due diligence and migration process from nine months to three, the M&A SPA can be significantly shorter, reducing the costs associated with the transaction while enabling the buyer to confidently embark upon new strategic plans.
ENDS
