Challenges

• LRN acquired a product line as a carve-out from a large organization with a variety of systems spread across a global footprint. LRN’s strategy called for the continuation of operations, but with a transfer of the existing operations into the LRN systems. This spanned go-to-market (GTM), revenue operations, product support, and engineering.
• The financial systems leveraged by the divesting company were diverse and in various states of consistency. Due to the limitations of the legacy systems and historical records differing by region, the process of standardizing data for transfer posed challenges. Beyond the structural complexity of the operations of this global billion-dollar company, the data faced normal hygiene issues we would expect to encounter in any organization of this scale. For example, duplicative customer records complicate renewals and require complex merging. The source systems required for this migration were not available for review by the project team due to the carve-out nature of the acquisition. Due to the sensitivity of the information and limitations of the ERPs in use, it was not possible to restrict access to only the relevant data. As such, only queries could be run to support the migration.
• For the top of the pipeline, the source organization leveraged a different CPQ product than LRN and operated in regions that were new to LRN, such as MEA and APAC. There were region-differentiated products, which were itemized over hundreds of SKUs in the product catalogue. LRN’s architecture focused on simplicity and configurability to keep its highly dynamic offerings easy to buy and sell.
• The Delivery and Service organizations supporting the product line operated on Jira and OpenAir. To allow for a seamless transfer of the product, internal and external service and ticketing systems were targeted for migration to LRN’s tech stack. Due to the access constraints of the carve-out acquisition and limitations to the source technology, the window for transfer of this data to achieve the desired transition was very narrow (one hour).

Solutions

• The project aimed to meet the goal of LRN’s strategy, to take an existing and long-lived product line from a divesting company and integrate it into its structure of technologies to continue functioning as-is while working to integrate operations. To meet this goal, we divided the project into the following components:

• Revenue Operations, customer, and contract migration
  • Go-to-market migration, including products, quoting, and document generation
  • Delivery organization migration, including internal project management, product engineering, and hosting, and internal ticketing
  • Service organization ticketing migration to support customers using the existing products
• Revenue Operations Migration
  • Our recommendation for the migration was to identify active customers across all regions: NORAM, LATAM, EU, MEA, and APAC. The aim was to produce standardized contract data in the LRN CLM (Ironclad), allowing for key details to be leveraged to assist the sales data migration coming from a variety of different sources, businesses with heterogeneous operations and data schemes (for example, no contracts were generated in some regions, or products had differing Terms and Conditions.
  • The financial data coming from a legacy implementation of SAP required a complex ETL to properly clean and reconcile with the sales data. We leveraged complex Excel and Alteryx to achieve the mapping required to provide the LRN accounting and FP&A staff to close the books for the acquired product with confidence.
• Go-to-Market Migration
  • The first step was to get the new sales staff brought over in the acquisition. We brought over the existing SKUs from the acquired product in a simplified and rationalized way that discarded previous distinctions for customer segment, selling region, or now irrelevant internal departmental codes. The newly rationalized products were quickly adopted by the acquired sales representatives.
  • Historical performance was aggregated, and pipelines were created to provide the leadership team with a view of the product’s performance and business that leaders had not had access to before the acquisition. New sales reps were able to achieve and show significant improvements over their sales and retention prior to acquisition.
  • New currencies were configured, and new templates were created for document generation – invoices, quotes, and automated dunning. The system was configured to support the new bank accounts and legal entity details across the documents. A new territory solution was created using Flows to support the new global business, previously only operating in the US and Europe, which now had a global footprint to manage, exceeding the limitations of its once semi-manual territory approach (with a heavy reliance on named accounts).
• Delivery & Service Organization Migration
  • The primary challenges for the delivery & service organizations centered on a professional-services automation tool migration: OpenAir to Mavenlink, which was the preferred tool for LRN’s organization. The second primary focus was on Jira content – both internal and external.
  • Due to security compliance, we were unable to access the divesting company’s Jira instance. Instead, we were limited in our ability to organize and relate data to customers. Further compounding issues were found when comparing service data to customer IDs that were duplicative or otherwise disconnected from an understanding of the customer entitlements.
  • We overcame issues related to data models and the APIs by connecting with the support & development teams of the corresponding PSA products. We developed a migration tool using Python for data export from OpenAir, staged the data in MySQL, and finally imported it to Mavenlink. To precisely track the migration of individual objects, the exported data (which was of substantial volume) was staged in an RDBMS.