Source: No Jitter
Give me six hours to chop down a tree and I will spend the first four sharpening the axe.
Failure is rarely something we plan for, but more often the result of failing to plan. This is true in life, and it's certainly true here in the world of unified communications. The most successful projects I've worked on unknowingly took the advice of President Lincoln and spent a significant amount of upfront time planning their approach, execution, and validation. At the conclusion of each project, we knew where we were and how we got there. While there were unexpected problems along the way (that's a given), even they were built into the overall plan. Accidents were anticipated and therefore, easier to manage.
As I have said here on No Jitter many times before, one of the primary responsibilities of my job is to move enterprises into the world of SIP. Sometimes it's as simple as a SIP-based application, but more commonly, it's a wholescale replacement of TDM trunks. Better yet, it's a move to feature rich unified communications clients.
Regardless of the size or scope of the transformation, every job required careful planning and execution. The last thing anyone wanted was to go from a system of old, yet working technology to a mess of uncooperative IP servers and soft clients.
Thankfully, there are tried and true methods to successfully facilitate removing those TDM trunks and digital telephones while avoiding catastrophe.
This is my step-by-step approach.
Who's on First?
Before you start any project, it's important to get the lay of the land. By this I mean, how are different business units currently using communications? Are the requirements of one department completely different from that of another?
As much as possible, meet with all the business unit leaders and a good cross-section of their worker bees to learn what they are happy with and what they expect after the new infrastructure is in place. The needs of a contact center agent are almost assuredly different from those of a field maintenance technician. You cannot design a system without taking into account all the players.
Are You Ready?
After documenting what it is you need to accomplish, it's essential that that same level of scrutiny is applied to what is already in place. Is the network ready for quality VoIP? Are there existing contracts that need to be ended or renegotiated? What is the state of the existing communications system? Has it been kept up-to-date with current hardware and software, or is it several releases behind. As the system has evolved, has the configuration kept up with best practices? Remember, what might have been correct three years ago may no longer be applicable to SIP.
The Dating Game
A conversion to SIP usually requires software and servers. For example, I would never bring in SIP trunks unless they came through a Session Border Controller (please see my article, 9 Reasons to Have Your Own SBC). I would also strongly suggest that you add a session management layer between your core communications equipment and your SIP entities. Session management is the path away from nodal solutions to an enterprise cloud of sharable, scalable, and elastic services.
In addition to buying new stuff, this is also a good time to reevaluate your trunk needs and the carrier (or carriers) that currently supply them. You may have been an AT&T customer for years, but Level3 might be a better choice for your future....and vice versa.
The point is that there are choices out there, and you need to spend some time evaluating different vendors and their products. Not all SBCs are created equal, and it's important that you find the one that best meets your needs and isn't simply the one your business partner wants to sell you.
As I wrote about in The Evolution of the SIP Trunk: From Pipe to Solution, different carriers offer features that weren't available on your TDM trunks. While some of the new bells and whistles may not be applicable to all businesses, there are quite a few that are real game changers. Don't miss out on something because you never bothered to look to see what's possible.
Kick the Tires
There aren't a lot of people willing to buy a new car before taking it for a test drive. The same should hold true for a big SIP transformation. Before a system is upgraded, all new features and workflows should be piloted. This means building a lab system that mirrors the functionality of your production system.
Go back to "Who's on First," and develop a pilot that exercises the requirements learned from interviewing the various business units and their staff. For instance, if accounts receivable is a big fax user and you intend to move your faxes to IP, you had better thoroughly test it.