Initial Install - mission critical environ - Best Practice

Hi All

I am exploring installing an asterisk system to replace a Toshiba (dksub/dksue) pbx box + voice mail box in a medical practice with around 45 users, and a T1 line (4 or so fax units).

Since the phone system is mission critical, I envision doing the swap in the following way while keeping the existing system as is:

Once installed, and configured, and tested as far as possible, I would initially hook the T1 into the new box on a weekend and have some staff help test the system. Every user would have two phones for a time.
If it passes that testing, I would allow the users to use the asterisk box for long distance via voip provider, while the old system is used for regular business.
Passing the above tests, during a quiet period, say a Friday afternoon, again plug the T1 into the asterisk, and have the staff try and test it more fully, and give it a load.
Back to the old system, this time giving the asterisk box a test during peak periods for a time…where if it passes that test, I could leave it in place, removing the old system after x weeks of testing.

Please see if you can shoot holes into my thoughts on testing.



Not a bad plan IMHO - especially phasing in long distance via VoIP is a very good idea. I’ve never gone through a comparable roll-out with Asterisk. Other communications systems though in my old job… gosh I love my new job so much more… my 2 cents, probably things you thought of already:

  • In phase 4, you need to manage stakeholders and communicate a lot. Even so, and if you repeat several times that there is a potential for a mix-up of voice mails left on Asterisk while users are back on the old system, or vice versa, there will be “lost” voice mails etc. You might have to take the plunge with Asterisk and not switch back and forth as often as you describe
  • On the weekends… Have a budget to order Pizza for everybody, including Veggie (;->). Try to get external calls by using cell phones (w/o using up tester’s minutes)
  • You’ll need to be able to respond on short notice during the entire phase-over in case something bad happens, or users believe something bad happens
  • Users, users. There will be complaining how things are different from how they’ve used to be, even if it’s an improvement.
  • Don’t expect gratitude. Users even might take advantage of the situation and roll over mistakes or negligence on their job into your implementation where they otherwise would have had to stand accountable (“I never got that call, the new system stinks”). Better know where the logs are, just in case… see above

What i did here, ~50 phones, 2000 calls per day:

I placed BOTH telephones on the desks of the employes.
They really need to get used to IP phones. The dialing and transfer handling is quite different and “normal” users need to get used to it.

I made a deal with the telco:
Place the E1 but dont charge it till we switch finally.
They all WANT customers, so they will do it :stuck_out_tongue:

Now you have enough line to dial out.
Block the old pbx for outgoing calls, that way the users get used to the new pbx when forced to use it :smiling_imp:

Echo problems, volume, transferhandling, hold and all this stuff will be worked out now, while the old PBX is still up.

Call the users from time to time and ask them to transfer you…hehe, pretty funny… (“uhm…how was this working again?”…)

Give it a few weeks, then they are familar.
“Psychohype” them into the new pbx.

Remember, customers !!ALWAYS!! tend to hate the new and love the old, so you always have a tough position installing something new.

The trick is, dont hype asterisk, let THEM do it… :wink:
Give them one or two very comfy functions so they can say how they love it.

Make their phone a bit LOUDER then normal. People tend to think “louder”=Clearer, better

Never say "Hey, its better sounding huh?"
"Hmm…my friend said he hears me much better and clearer, is this the same with you ?"
You WILL hear a “yes, its amazing”…

Stresstest your asterisk with similar calls initiating MOH, voicemail and queues similar.
Asterisk is bridging these calls (doubling the used channels), multitasking into MP3 MOH, playing backgroundfiles (voicemail) etc.
On a 3GHZ machine with no codecconversion (G.711 is ISDN standard)
you shouldnt exceed 10-20% CPU on the machine !

The most CPU is needed for echocanceller and codecconversion.

Also make sure, your “Fax strategy” is clear.
I am using a second server with Hylafax and virtual IAX-Modems (open source) bound to it.
Works absolutely flawless !

Good luck buddy !

I think you need to agree early on and possibly have the customer sign off:

What are the key requirements and test build the test plan around these
what exactly will be deemed success
what exactly will be deemed failure

create a feature test form and have them fill them in!
you can file them and then hand them over at the end as part of the hand over documentation

Be careful not to have unmeasurable standards like “good sound quality” or quick call routing. What is good? You may be better to have “sound quality acceptable by john and jane” or "call quality now lower than that of an analogue line.


Very good advice all round.

It is a must to have a “definition” of what the client is asking for beforehand, and a sign-off afterwards.

The VOIP for long distance aside, I would expect the sound quality to be equivalent to current Toshiba phones on a Toshiba dksub & sue? In this instance, the system is only on the internal cat5 network and the T1 trunk?

The tip about having the users use the new phones wherever possible to learn the day to day functionality is an excellent one. I would have them use the new system for all internal calls and long-distance for training…even local calls could be via voip provider temporarily for training purposes (the T1 would be on the old box during this time).

The actual T1 switch from old system to new cannot be teamed up with a second T1 as far as I can see. I will ask however, but imagine the phone company will have to exert X effort to make that happen and therefore would decline?

I appreciate your helpful advice.

What i did here was, i had the telco installing a new, a second E1 (European version of T1) PMX installing.

The telco faked the CLID on this PMX, it was identifying with the number from the old PMX - so a customer called from the new PBX/PMX was not confuzzled by seeing a new/diff. number.

I blocked the old PMX for outgoing calls and had the users using the new one that way.

The deal with the telco was, to NOT charge the new PMX for the “transition time” to the new system (3 month).

After 3 month, the old PMX was removed, the new configured finally to the old number(s) and charged regulary from then on.

The telco agreed to this deal because of the unbeatable arguement:

  1. We work long enough together and u gain good money from us
  2. I have an offer from another telco doing what we need…
  3. Dont you want to be our partner the next 15 years ?

Have the sales-person from the telco calling you.

I dont know how big your company is, but our is big nuff to ask for deals like that 8)

any chance of phasing in the Asterisk system as part of the deployment? Add a dial plan to call between pbx systems with 3/4 digit dialing (what ever you are using). Pick a few users to roll their primary phones over to Asterisk using the functionality you plan on. They can have a second phone on their desk as a backup if needed. Run in production like this. It won’t replace the stress testing but is a good way to phase in. Also - give those users great features so that others get envious and there is ‘pull’ created by the users to move to the new system…


Based on my current VoIP project, which involves moving about 2000 phones from Centrex lines to a new <$$$ brand name> PBX, I can suggest the following.

  • All phone systems are mission critical. People have a belief that their phone will just work, no matter what. If you aren’t sure you can provide this, don’t change your phone service, period.

  • You may be able to run the VoIP system in parallel for desk to desk calling, even outgonig calling if you can spare the PRI or VoIP trunk. If you can do this, get your users used to the system before switching your incoming lines.

  • If you are going to do all the switching, don’t involve the end users, just do it with technical people. Only involve them once you go live with the VoIP system. Your giving your users too much credit in my book.

  • Don’t go back once you go live. People can barely use one phone / voicemail system, don’t try and give them two.

  • Keep your old system handy (like your planning to) for as long as you need to ensure success. Just remember, if you switch back people they are going to loose voicemail, settings, etc. They will complain, even if they asked you to switch back.

  • Try to make it a positive cheese move (see the book “Who moved my cheese?”) and people may be more receptive. Involving the users and getting feedback may help with this (even if their feedback doesn’t mean anything).

  • If you have time, do a pilot with some of your more forgiving users to work out the bugs. If not, at least use the system yourself for a few weeks before rolling it out.

  • Test your computer network! If you haven’t already done this (I’m sure you have, but…) it’s essential to ensure that your not going to get dropped calls, jitter, etc. This is double important if your not the network guy, because you may not be able to fix it. Speaking from experience, data people are much more of the “I can just fix it if it breaks!” type than phone people.

You can also iron out a lot of the basics initally with a test machine and a few forgiving users.

Develop all your dial plans and what your users expect from the system.

Once this is done and you are happy you can invest in serious kit.