There are many aspects to consider when migrating to a new entitlement management system. The last two blogs of this series covered migration approaches and how to handle difficult data. Now, let’s have a look at project management best practices.
Before you start migrating your entitlement management system you should take some time to plan your project accordingly, align with stakeholders and ensure you have the resources available that are needed to manage the project.
Migrating an entitlement management system is not just a data migration project. Typically, it involves process changes, impacts many parts of the organization, the customer experience and many other areas.
Migration Projects Impact Many Parts of the Organization
- Sales – opportunities may have to be entered differently and new entitlement management solutions often require more accurate data that typically comes from the opportunity
- Orders Team – order validation might be different
- Software Operations – product configuration and licenses are often different
- IT – build new integrations and migrate data; install, maintain and monitor the new system
- Product Management and Marketing – the new customer experience will have to be communicated
- Legal – more data may be captured or displayed to customers and this might require new EULAs or other data privacy changes
- Engineering – new and old license keys need to be validated to make sure they work with the new system
- Finance – ensure that revenue recognition doesn’t change
- Renewals team – validate that renewals will still be processed, end users will be provided with the right information and reminded to renew
- Support – validate that customers can use the system and that the support team is trained so they can help end customers and channel partners
- Executives – apprise the executive stakeholder of the status and changes as system migrations often contain risk
- Channel Partners – need to be trained on new system and new capabilities
- End-Customers – need to be trained on new system and new capabilities
Implement Standard IT Control Processes
As many different people are involved in a migration project, you should implement standard processes to ensure that everyone is aware of the changes and the project runs as smoothly as possible:
- Bi-weekly stakeholder meetings with red/yellow/green status, next iteration targets and a discussion of unresolved issues
- Meetings with the core team to identify issues: The core team should meet twice a week and include representatives from the most common users including orders, software operations, product management, IT, renewals and support
- Test coverage tracking to ensure that most of the scenarios are covered/handled by the new system
- Make sure a given percentage of orders are entered in both the old and the new system about one or two weeks before go-live
Define go-live criteria to make sure the team has attended to all critical areas.
- At least 10% of migrated data has been validated manually
- All directly involved departments, including Software Operations, Renewals and Support, consider themselves trained and ready to help customers
- License key generation has been validated by Product Engineering
- At least 10% of the orders have been pushed to both the old and the new system for two weeks with no issues
- End-to-end user experience has been signed off by all accountable parties
- All department heads have signed off on go-live (see list above)
- IT hosting has validated the hardware/infrastructure will handle the go-live volume of concurrent users, has implemented monitoring and tested fail-over switching
- “Reverse back to old system” if catastrophic event occurs has been tested
When you approach the end of the project, there are a few best practices to consider when planning the actual go-live:
- Migrate Data Into Production Over Time – Not on Migration Weekend
If there is a large amount of data to migrate, one weekend won’t give you enough time. Consider migrating the older data (entitlements, licenses, organizations and users) into the new system in the week before the go-live. This will give you more time to migrate changes only on the migration weekend.
- Test with Final Hardware and URLs before Go-Live
Make sure you test everything with the final URLs and final hardware before going live. This burn-in period should occur during the test phase.
- Schedule Go-Live Early in the Week When Everyone Is Available
It is less than ideal to go-live on weekends because less people are available. It is better to target going live on a weekday such as a Tuesday so that all hands are available and able to react quickly.
Readers also liked:
- Software Licensing 2016: Seismic Shifts - Shaky Foundations Report
- Hear Why You Need a Software Monetization Partner – Not Just a Vendor