Total Time from Unity Sale to Deployment: 13 Months
Total Staffing Involved: 25 Equivalent Headcount total across customer, partner and Cisco
Strategy: Perform extensive lab testing, bring Unity up in parallel with legacy system, cut over a small number as a pilot followed soon after by remainder of the enterprise.
Benefits of the Flash-Cut Approach
Migration is much shorter and therefore can be more cost effective.
Training can be synchronized corporate-wide. This leads to economies of scale as a single message campaign goes out to the whole company.
The only integrations with legacy voicemail systems are intended to be long term, therefore the effort expended getting them configured and working properly is not "throw away" work.
Full new feature set uniformly available to all users.
Simplified integrations to legacy systems and simplified VM dial-plan complexity.
Simplified user training. No need to train users or confuse users on how to message to legacy users and retrain when those users are migrated to new platform. IE: Network message. The process to send a message to Joe User might/could change after they're migrated to new platform.
Simplified Distribution List creation. (For example, in one deployment with 2500 DL's and 20k users, there would have been no way to properly maintain the DL's between the 2 systems.)
Drawbacks of the Flash-Cut Approach
If an issue is experienced system-wide, it will impact a larger number of subscribers than if the rollout was incremental.
Lack of Internal Support staffing exposure and time to ramp up could lead to possible extended downtime.
Initial additional work to import subscribers and perform validation tasks.
More demand on user training since training might be limited to a single week. Not all users might get trained due to PTO etc.
Higher demand on the system during self-enrollment period. Self/Pre-enrollment needs to be open sooner depending on user base.
Help desk demand and staffing following the cut is higher for the first few weeks so higher staffing needs may be required.
Requires a significantly larger amount of pre-planning compared to an incremental migration.
Depending on the configuration and integration, the fall-back plan can be complicated.
Requires that deltas be maintained between the two systems for user changes, for example, new employee addition or termination and deletion between the time when subscribers are imported and the cut-over date.
Likely requires more total peak staffing to execute and follow up at cut-over time and 1-2 days after.
Gradual Roll-Out Migrations Example and Overview
Benchmark: 35,000 Voicemail Only Subscribers
Total Time from Unity Sale to Deployment: 20 Months
Total Staffing Involved: 20 Equivalent Headcount total across customer, partner and Cisco
Strategy: Perform extensive lab testing, progress through cutting subscribers over to Unity incrementally starting with pilot deployments and following up with cutting over per logical partition such as departments or geographic area.
Benefits of the Gradual Roll-out Approach
Limits the exposure to smaller groups of subscribers with each cutover, therefore allowing for more focused attention if things go wrong.
Allows additional time for support staffing exposure and training.
Allows additional time to import/create user base and validate feature sets.
Lower demand on the system during each self enrollment period.
More uniform demand/impact on Help desk and staffing during the migration.
Depending on the configuration and integration, the fall-back plan may be simpler than in a flash-cut migration.
No requirement to maintain deltas between the 2 systems on users changes. IE. New employee, Employee termination and deletion prior to cut.
Drawbacks of the Gradual Roll-out Approach
During migration, this approach complicates integrations to legacy systems and adds to VM dial-plan complexity. Each incremental step requires integration work to the legacy system that is only temporary and will be removed once the following incremental steps are taken. This can actually create more risk, as there are more opportunities for things to go wrong.
Increases risk of allowing customer to go back to old system simply because new system is different (seen at CCE w/PIMG).
Gives competition more time to FUD the customer and position their newer offerings.
New feature set is not uniformly available to all users during deployment. Some features may not be available until all users have migrated.
Complicates user training. During depoyment, users must be trained on how to message to legacy users, then retrained when those users are migrated to new platform.
Adds complexity to Distribution List creation, as distribution lists must be maintained on both legacy and new systems during migration.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:
