Intra-Domain Migration Federation

This is the second part of a three part series of blogs looking at scenarios for short-term and long-term intra-domain federation as well as inter-domain federation.

In the last blog, we discussed the issue of M&A or other events leaving the IT department with a legacy of multiple unified communications (UC) platforms.  That blog addressed the long-term co-existence approach; this blog will address the alternative approach, which is to migrate users from one system to another.

By far the cleanest UC strategy is to have all users on a single platform.  Having multiple platforms with disparate feature sets impacts the overall user experience as well as creating all kinds of administrative costs, such as those of dual-management and configuration.  Additionally, depending on the chosen integration strategy, concurrently maintaining 2 (or more) UC systems often requires a separate domain for each system (e.g. lefthand.xyz.com and righthand.xyz.com) to allow each UC system to be ‘authoritative’ for its domain (which is another way of saying to avoid routing and addressing clashes).

However, conducting a ‘flash-cut’ migration has numerous risks, not least of which is ‘leaving some users behind’ in terms of failing to cause them to become invested in the new system via training and other exercises.  Therefore a system migration is not an event, but rather a process that may take many months, depending on the size of the user base to be migrated.  Retaining the option of moving blocks of users back to the previous system is essential, even though it would be a last resort.

One requirement of the migration strategy is to create a temporary bridge between the two systems to allow at least some form of intra-domain collaboration to be conducted between the 2 systems during the migration.  This could be effected through the deployment of a specific purpose gateway, such as a Sametime:SIP gateway.  An ‘any-to-any’ intermediation solution such as a Session Border Controller could also be considered.  The downside of both of these strategies was evaluated in the ‘Co-existence blog’, but for temporary migration usage, an additional consideration is that the expense of these gateways is not justifiable, if it can be avoided.

An ideal migration strategy would be one that did not require the creation and maintenance of multiple ‘authoritative’ domains; one that removed the overhead of managing complex, error-prone intermediation; one that could be implemented for a finite period without large and non-recoverable capital outlays and one that could be closed down when the migration exercise was complete.  Such a migration strategy would probably look a lot like NextPlane.

Advertisement