Migrating a legacy application to Salesforce is not just a technical challenge; it’s a strategic move toward innovation, efficiency, and scalability. However, the transition can be complex, affecting hundreds of customers with varying needs and integrated third-party systems. This post outlines essential strategies to ensure a smooth and successful migration.
When considering complex app migration for your customers, one should consider that it’s as much about organizational readiness as it is about feature parity and data migration. We would like therefore to frame the approach with three distinct tracks that require dedicated teams, coordinated through outcome-focused program management.
- Product Feature parity
- Migration tooling
- Implementation and Change management
Product Track
1. Guarantee Feature Parity, but Do Not Aim for 100%
The first step is ensuring that all key functionalities of your legacy system are mapped and adequately replicated in your new Salesforce solution. Detailed analysis and planning are vital to identify and bridge any gaps in functionality. We would not advise replicating 100% of the existing features, as this kind of migration should help to remove some technical debt. Therefore some features, like features with poor adoption, should not be migrated.
We recommend creating a feature-by-feature mapping of the old system to a new one. This is a practical first step in developing a test suite that will be essential later in the process.
Once the new solution is ready, we recommend creating a sandbox environment of both the old and the new applications, that are populated with live-like test data and have your QA team go through both apps feature by feature, comparing functionality as well as user experience. There may be different ways that the same function is performed, and hopefully, the new system will be more efficient and user-friendly, and such differences should be clearly documented. It’s always a good idea to include Business Users or SMEs from real customers, alongside your QA team. Without deep business knowledge, QAs may miss important details (especially if the system is not working exactly in the same way, and has improved or simplified some processes).
Particular attention should be paid to reports, making sure that both systems report data in the same way. Any gaps in functionality or reporting should be documented.
2. Consider Customizations
Many of your customers may have customized or extended the functionality of the old system. This should be taken into account when preparing for the migration to the new solution.
Our recommended approach would be to divide your customer base into three broad categories:
- No customization and limited complexity, using the app out of the box.
- Minor customizations that can be matched with the customization capabilities of the new system.
- Major customizations that require custom development to extend the new solutions’ out-of-the-box features.
The first group should be able to switch over to the new system with minimal disruption, enjoying the improved user experience and functionality.
It may be sufficient to address the needs of the second group (Minor customizations) with a simple instruction manual to apply custom configuration to the new system, either by your implementation team, or the customer itself.
Major customizations may require a product development project to address the specific needs of each customer.
In both cases, if you find similar customizations across a number of customers, it may be considered by your product management as an opportunity to include this custom functionality in the core product.
3. Integrations
If your product relies on integrations with third parties, those would need to be supported by the new solution.
Consider creating a proxy layer that can be used to support external integrations while enabling connectivity to both your old and new systems. This will allow you to remove the complexity of re-building and re-certifying each integration with external vendors. Instead, you can deal with this in-house and de-couple your products from vendors’ endpoints.
It is important to have an end-to-end testing environment set up with each of your external vendors. Investing in that early, and creating a test automation suite will allow you to make sure that integrations will not break when switching your customers over.
4. SIT Process
Once development is complete, do not overlook the importance of full SIT testing. Having a test environment that is integrated with all external systems and loaded with real-world data (obfuscated, of course!) is essential. You may need to set up multiple test environments to support different types of customers.
We would recommend having an SIT team that is independent from the development team, to provide an independent round of testing. The SIT team should look at the new system with a “fresh pair of eyes” and test against scenarios that have been developed based on real customers’ usage of the solution.
Remember that at this point we are testing the product, its customizations, and standard integrations to external systems. We are not testing each customer’s specific configuration, yet.
Migration Tooling Track
The Migration Tooling track is there to ensure that the migration process is automated, reliable, and repeatable. It is designed to support the needs of a smooth transition and facilitate rollback in case it is needed. A properly designed migration suite will handle the complexities of your customers’ data structures, customizations, and the specific requirements of Salesforce.
1. Migration Suite
When creating the migration suite, look for the following capabilities:
- Data Extraction: Efficiently extract data from the legacy system, including handling complex data structures and relationships.
- Data Transformation: Apply necessary transformations to ensure compatibility with Salesforce’s data model, including mapping fields, converting data types, and applying business logic as needed.
- Metadata Handling: Automate the migration of metadata, including custom objects, fields, reports, user roles, and security settings, ensuring they are correctly configured in Salesforce.
- Staging Database Utilization: Use a staging database to validate data and metadata before migration. This intermediate step allows for data cleansing, deduplication, and integrity checks, ensuring only accurate and optimized data is migrated to Salesforce.
- Incremental and Delta Migration: Support for both full migration and incremental updates, enabling ongoing synchronization between the legacy system and Salesforce until the final cutover.
Migration of user-profiles and user-specific settings should be automated as well. The security model of the new system may be different from how it’s handled in the legacy product. Salesforce allows for an extremely flexible role-based and permission-set-based security configuration, and well-designed security and access configuration will allow for a very nuanced data access policy. This comes with a degree of complexity and often the need to map existing products’ configuration to Salesforce-based access controls.
Migration of user login credentials is another step to consider in your migration strategy. When the switch-over takes place, users would be expected to start logging in to the new system. If possible look for a single sign-on approach that supports both the legacy app and SFDC platform. User management is always tricky so reducing the first point of change and friction is a smart investment.
If single sign-on to both systems is not feasible, you’d need to work out a process that would prompt the user to set the password to the new application through a secure link on the first login.
2. Staging Environment for Migration
A staging database that would hold metadata and data during the migration process would provide a number of benefits. You would be able to stage and transform the data reliably before importing it into the new system. In case of any data issues during the migration, having a staging database will allow for retries, rollbacks, and data correction activities. Additionally, many clients choose to use the staging process to clean up the data before it gets imported.
When designing a staging environment, consider these points:
- Configuration: A robust staging environment should include an import-ready database that would mirror the original and the target data models (pre and post-transformation), allowing for thorough testing and validation of migrated data and metadata before it’s imported.
- Validation Processes: Implement automated scripts within the staging database to validate data integrity, compatibility, and performance, ensuring the migrated data meets your quality standards.
- Security Measures: Ensure that the staging database adheres to strict security protocols, protecting sensitive data during the migration process.
The migration suite should be thoroughly tested. End-to-end testing should include a comprehensive test of the migration wizard in conjunction with the staging database, simulating the migration process to identify any issues in data, metadata migration, and integration with third-party systems.
Implementation Track - It Gets Real When It Gets Real
It is hard to get real feedback from customers until they are in production. It gets real when it is real. Have a phased rollout strategy that starts with customers who have a history of being diligent in pre-production testing and are collaborative.
A detailed change management plan is crucial for minimizing disruption. This includes clear communication with all stakeholders, comprehensive training for users, and robust support systems to address any issues promptly.
The user experience should be at the heart of the migration strategy. Aim for a seamless transition with minimal downtime and ensure that users are supported throughout the process. This might include retaining familiar interfaces where possible and providing extensive training and support.
As we look at the three types of customers outlined earlier in this article, we should develop a staged approach to address each of these categories.
Type 1: Customers with limited complexity, using the app out of the box
We would recommend starting with limited-complexity customers and creating a migration strategy that will automate most of the steps of the migration process for this group.
The migration suite should be able to handle the migration of these clients automatically. As with any software development project, it’s a good idea to initially migrate a small sample of these clients, performing thorough verification of all steps of the migration process. Increase the pace of customer migrations once your process demonstrates it is ready. Don’t fall victim to publishing an ideal calendar.
Once the initial set of customers is migrated and verified, you can move on to migrating the remaining group.
Type 2: Customers with minor customizations that can be matched with the customization capabilities of the new system
These customers may require a professional services engagement to migrate their data and ensure that customizations are in place. Having the migration tooling suite will greatly assist in this process, but each customer should be regarded as a project.
Type 3: Customers with major customizations that require custom development to extend the new solutions’ out-of-the-box features
These clients present the most complexity and risk, not only due to the high level of customization but also because typically they will involve large volumes of data to deal with.
We recommend creating a project implementation plan for each account. The project plan should include Discovery and Analysis, a full sandbox environment with SIT and UAT testing, and a live migration plan with proper change management in place.
Particular attention should be paid to performance testing. The test environment should support real-live data volumes and test integration endpoints.
Before the start of the migration, a full UAT plan should be executed.
Risk Mitigation
Risk mitigation should be a top priority. Always have a backup, and always be ready to roll back in case anything goes wrong. The mindset should be “zero downtime” and “zero defects”. While in practice there may always be unaccounted-for use cases and data issues, being ready to mitigate such risks in real-time is what separates a successful project from a nightmare.
Conclusion
Migrating your existing application to Salesforce offers a host of benefits, including platform benefits, configuration capabilities and customization options, scalability, and access to a suite of cutting-edge tools and features. However, the complexity of such a migration cannot be understated. Dedicating time to designing a reliable migration process with attention to feature parity, automation tools, and change management policies, application vendors can navigate the challenges and ensure a successful migration of the application with minimal disruption and risk.
Remember the most important migration to any customer is theirs. You are making a major change to their business (hopefully for the better) so treat it with the care it deserves.
At Aquiva Labs, we leverage our deep expertise to make your migration journey as smooth and effective as possible, setting you up for success in the Salesforce ecosystem.
Written by:
Nikolai Balba
CEO
