RECOMMENDATIONS Cutover - Best Practices (PBX -> PiaF)

Robert-BCC

Rank amateur
Joined
Jul 21, 2014
Messages
68
Reaction score
13
Hi,

On Monday August 25th, I am converting the non-profit, non-tech-saavy Bay Area Cancer Connections to their new home, and their new IP telephony system. Thanks to all of the suggestions so far in my initial thread, they'll be moving from a legacy PBX to Vitelity Hosted PiaF server that I am setting up next week. I have hired a Vitelity consultant to ensure that the setup is secure and reliable. I have made the necessary number porting requests and would like some best practices about making for a smooth cutover. Some things that I'm thinking about:

- The number ports are "FOC Received: 08-19-2014" (six days before they move)
- Schedule the number port cutover for the Sunday before the Monday when they'll begin operating out of their new home. Will AT&T permit a scheduled cutover? On a weekend?
- Do not bother setting up handsets at the old location (firewall / poor bandwidth etc.)
- Once I have the PiaF and the handsets setup mid-next week, begin training individuals on how the system works.
- Create documentation on how to administer extensions (probably after the cutover), backup/restore the config, how to check for periodic updates, and ...
- What else am I missing?

Thanks,

Robert
 

kenn10

Well-Known Member
Joined
Dec 16, 2007
Messages
3,764
Reaction score
2,173
I would be concerned about the numbers porting when you want them. Both Vitelity and at&t rely on the number portability division and when you port from one provider to another, it is my experience that you get no notice until it is done. Y ou need to work closely with Vitelity to see if they can actually schedule the cutover. Otherwise, you may have the numbers at the new location on the 19th and the old location dead in the water.

I'm sure you're already versed in training people more on the similarities (how you transfer a call, call park, page, etc.) rather than making it seem like the new system works very differently. Keep things familiar to the users rather than shoving "this is all going to be totally different" at them.

If you are setting up and leaving it to them, you'll want to train someone in how to look at the CDR to keep an eye out for hacks and such. Otherwise, you seem to be on the way to a good implementation.
 

rjaiswal

Active Member
Joined
May 24, 2013
Messages
438
Reaction score
58
In my experience, carriers don't port on weekends.

If possible, setup a call forward on the POTS line to point a Vitelity DID.

On the PIAF, setup an inbound route for the POTS line, so when it's finally ported, it'll start working automatically.

I've only been able to schedule a port, when porting large numbers of DIDs, on PRI or larger trunks. And that only happens on weekdays.
 

islandtech

Wassamassaw
Joined
Jan 11, 2009
Messages
677
Reaction score
137
One recent cutover I had the local phone company setup remote call forward(with multiple fwd paths) to a temporary voip DID on the new system. That turned out being a good idea due to issues during the port (took seven weeks to port). Customer never missed a call before, during, or after the cut.
On another cut, the customer's number could not be ported. (Yes there are some areas and rate centers that can't port in or out.) Had the local phone company pre setup permanent remote call forwarding (with multiple forward paths) to the new voip DID. On the day of the cut, called the local phone company contact who activated RCF while talking to him.
 

Robert-BCC

Rank amateur
Joined
Jul 21, 2014
Messages
68
Reaction score
13
One recent cutover I had the local phone company setup remote call forward(with multiple fwd paths) to a temporary voip DID on the new system.
Why was it necessary to have more than one forward path?

Thanks for all of the helpful suggestions. Reviewing the CDR reports is smart and now on my list. I will try and delay the cutover till Friday, and setup a way to "catch" the traffic before the line is transferred to Vitelity. I had my first porting lesson last week when I submitted the port transfer request for the 800 number and it was completed 12 HOURS after I submitted the form. That created an outage before Vitelity helped me forward the traffic the existing (and still not transferred) DIDs. So much for to "3-6 weeks per transfer request."

Anyway, here are the procedures I plan to document. Any omissions?

  • How to access the virtual PiaF server
  • Add new Phone
  • Add / Delete employee extensions
  • Modify recordings
  • Backup and recovery
  • Review CDR reports
  • Update PiaF / Centos·
 

islandtech

Wassamassaw
Joined
Jan 11, 2009
Messages
677
Reaction score
137
Multiple call forward paths are needed to handle more than one incoming call at a time. Other local phone companies might call it by different names. It's like rollover on PSTN lines.
The 800 number usually rides on top of aDID or PSTN line. Just has to be pointed to the new number.
 

geopeterwc

Guru
Joined
Aug 17, 2010
Messages
385
Reaction score
131
... So much for to "3-6 weeks per transfer request."
I "converted" an existing Pacific Bell phone number to UVerse a few weeks ago. It took AT&T almost two weeks to port the number to UVerse after AT&T had committed to install the new service. Go figure - PacBell was acquired by AT&T, and so the "port" was within the company. It still doesn't make sense to me why the delay, but it was my understanding that other PacBell phone numbers transitioning to UVerse are problematic.

The point of the story is that since you're in Palo Alto, and if the phone numbers at BCC were Pacific Bell phone numbers at any time in their history, that porting them to Vitelity might take longer than you're expecting. Then again, porting out of PacBell/AT&T might be less difficult than converting the number to UVerse.

YMMV!

/Pete./
 

Members online

Forum statistics

Threads
25,778
Messages
167,504
Members
19,198
Latest member
serhii
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.
Top