Plano, TX
VoIP Migration Services for Plano TX Medical Practices
The technical part of changing phone systems takes a day. The migration takes a month, and most of what determines whether it goes well happens in the weeks on either side of the cutover rather than during it.
Book a Demo
Practices that treat the switch as the project tend to have a difficult fortnight afterward: staff learning the system on live patient calls, a configuration that was never tested against how the practice actually works, and nobody quite sure what the fallback is.
Cleod9 provides cloud communication for Dallas-Fort Worth businesses. This page is about everything around the switch for a Plano practice: preparation, training, testing, the fallback, the first week, and the review at thirty days. It is operational guidance about communication and workflow. It does not address clinical matters and nothing here is guidance about patient care.
Build it before you need it
The new configuration should exist, complete, and be tested before the day the numbers move.
That means the greetings recorded, the menu built if there is one, the routing decided, the groups populated, the hours set, the after-hours path working, and the voicemail or capture destinations pointed at real people. Not sketched, built.
Providers can generally supply temporary numbers for exactly this purpose. Call the temporary number and walk the whole tree as a patient would, before anything real depends on it. Everything found at this stage costs nothing to fix.
A practice that builds the configuration on the morning of the cutover is testing it on patients, and patients are not a test environment.
Write down how the practice actually works first
Configuration is where a practice quietly recreates whatever it had before, including the parts that never worked.
Before anything is built, write down the real answers to a short list. Who answers the main line and in what order. What happens when nobody picks up, and after how many rings. Where refill requests go. What happens at lunch. What the after-hours arrangement is and who is on call. Which calls should reach clinical staff rather than the front desk.
That page is the specification. Handing it to the provider produces a configuration that matches the practice; describing the old system produces a copy of the old system.
It is also the moment to fix the two or three things everyone complains about. A migration is the cheapest opportunity a practice gets to change how calls are handled, and practices that skip it wait years for the next one.
Parallel running, and what it is good for
Running both systems briefly is useful and it is often misunderstood.
What it does well: it lets staff use the new devices and learn the new handling while the old system is still there as a safety net, and it lets the practice test the new configuration with real internal calls before external ones arrive.
What it cannot do is carry the same number on both systems at once. A number lives in one place, so parallel running means the new system on temporary numbers alongside the old one on the real ones, until the port completes and the arrangement inverts.
Two weeks is plenty. Longer than that and staff start treating the new system as an experiment rather than as the thing they are moving to.
Train before, not after
The most common migration complaint from front desk staff is that they were shown the new phones on the day.
Train in the week before, on the actual devices, with the actual configuration. Not a demonstration to the group, but each person doing the things they do every day: answering, transferring to a person, transferring to voicemail, putting a call on hold, reaching the clinical area, checking messages, and using whatever the practice's capture path is.
Twenty minutes each, hands on, is enough for most staff and it is the difference between a smooth first morning and a week of small failures in front of patients.
Pay particular attention to transfers. Transferring a call is the single most used function at a front desk and the one most likely to be done differently on a new system, and a dropped transfer is what a patient actually experiences as the practice being disorganized.
What to test before you rely on it
A short list, run against the new configuration before the cutover and again immediately after:
Two people, thirty minutes, one from an outside phone and one inside. It is the highest-value half hour in the whole project.
- Call the main number from an outside phone and listen to the entire greeting without pressing anything.
- Press every option and follow where each one goes, timing how long it takes to reach a person.
- Let the main line ring with nobody answering and confirm the call goes where it is supposed to rather than nowhere.
- Transfer a call between two staff members, including a transfer that the recipient does not pick up.
- Leave a message on every destination that takes messages, and confirm somebody receives each one.
- Call after hours and confirm the after-hours greeting and path behave correctly.
- Confirm the emergency address registration is correct for the practice's location.
- Test the fax line if the practice still uses one, in both directions.
The greeting deserves its own attention
A migration is when every greeting gets rerecorded, which makes it the moment to get them right rather than to reproduce what was there.
For a medical practice the instruction to hang up and dial 911 for a medical emergency comes first, before any options or information, and it stays first regardless of how the rest is later reorganized.
Then the practice name, then what the caller needs. Record it in a quiet room rather than at the desk, keep it short enough that a caller can act within about thirty seconds, and listen to the finished version from an outside phone before accepting it.
Record the closure and after-hours versions at the same sitting while whoever is doing it is set up, and keep them saved so they can be switched on without a support request.
Decide what going wrong looks like
Every migration should have an answer to the question of what happens if this does not work, decided before the day rather than during it.
Establish, with the provider, what the options actually are: whether routing can be changed quickly, where calls can be sent if the new configuration behaves unexpectedly, and how fast that takes effect. Then decide who at the practice can make that call and on what basis.
The most important protection is one already covered elsewhere: the old service stays running for several weeks after the port. A practice that has not cancelled anything has options; a practice that has cancelled everything has none.
The first day
Reduce the schedule. A lighter day costs the practice a few appointments and buys the capacity to handle problems without a full waiting room.
Name one person who owns the day, with the provider's support number, the account details, and the authority to make decisions. Not a group.
Have somebody call in from outside every hour or two for the first day. Internal testing tells you the system works for people who know it; an outside call tells you what a patient hears.
And tell the staff what to do if something is wrong: report it to the named person rather than calling support individually, and keep working. Four people opening separate support cases about the same issue produces four partial investigations.
The first week, honestly
Some things will be wrong and they are usually the same things.
A destination that goes to somebody who no longer does that job. A menu option that made sense in the specification and does not in practice. Ring timing that is too long or too short. A group that is missing a person. Somebody who cannot work out how to transfer. A greeting with a mistake nobody noticed until the fortieth time they heard it.
Collect them in one place rather than fixing them ad hoc, and have the named person take the list to the provider once a day rather than as each one surfaces. A week of that produces a settled system; a week of individual reports produces a confused one.
Ask the front desk directly at the end of each day for the first week. They will not volunteer problems while they are busy, and they know all of them.
What patients should notice
Nothing. That is the standard.
They should not be told the practice is changing systems, they should not hear anything about a transition, and they should not experience a different quality of service. A migration that patients can detect is one that did not go well.
The exception is the number, which should not change. If for some reason it must, that is a communication project of its own and it needs the same treatment as an office move, with early notice and every place the number is published corrected.
Do not change three things at once
Practices frequently combine the phone migration with something else: a new scheduling system, a move, a messaging launch, or a staffing change.
It is understandable and it makes every problem untraceable. When the phones, the software and the layout all changed in the same fortnight, nobody can say which one caused the thing that is now not working, and the front desk is learning three systems simultaneously.
Where the timing is genuinely unavoidable, sequence them by at least a couple of weeks and decide in advance which one is the priority if both need attention on the same morning.
The thirty-day review
An hour, with the numbers rather than impressions:
Then make a small number of adjustments rather than a redesign. Thirty days is enough to see what needs changing and not enough to justify starting again.
- Calls that reached nobody, compared with what the practice measured before the change.
- Where calls are ending: a person, a capture, a mailbox, or nothing.
- How long the main line rings before something happens, and whether that threshold is right.
- Any destination receiving calls it should not, which the reporting will show and nobody will otherwise notice.
- What the front desk says, which is the measure most likely to be accurate.
- Whether the old service can now be cancelled, having confirmed every number is live on the new one.
Common questions
How long should the whole migration take?
Plan for six to eight weeks from first conversation to cancelling the old service, most of which is preparation and the overlap period rather than work. Practices that compress it to two weeks are usually skipping the testing and the training.
Should we keep our existing handsets?
Sometimes, depending on what they are, and it is worth asking rather than assuming either way. What matters more is that whatever the practice uses is consistent across desks, so that support is one conversation rather than six.
Who should own the project at the practice?
One person with enough authority to move the date and enough time to do the preparation. Practice managers usually, and the choice matters more than any technical decision in the project.
When is it finished?
When the old service is cancelled, the thirty-day review produced small adjustments rather than surprises, and nobody at the front desk is still asking how to do something they do every day.
The things that are not the phone system and break anyway
Every practice has a handful of devices quietly using a phone line that nobody associates with the phone system, and a migration is when they surface.
The fax machine, if the practice still has one, which for most medical offices is still load bearing whether or not anybody likes it. The alarm system. The elevator line in a building the practice occupies. A credit card terminal. Occasionally a piece of clinical equipment with a modem in it that has been dialing out unnoticed for eleven years.
Find them before the port rather than after. Walk the office and look for anything plugged into a phone jack, then check the current bill for lines the practice cannot account for. Each one needs a decision: move it, replace it, or leave it where it is on a separate arrangement.
The safety-related ones deserve particular care and are worth confirming with whoever maintains them rather than assumed to be fine. An elevator line that stops working is not a phone problem until it is, and it is the sort of thing discovered at the worst moment.
None of this is difficult. It is only ever a problem because nobody looked, and looking takes twenty minutes with a flashlight and a copy of the bill.
Pick the week deliberately
A practice can choose when this happens, and most choose whenever the provider offered.
Avoid the first week of the month and the week after a holiday closure, which are the heaviest phone weeks in most practices. Avoid a week when a provider is away, since the practice is already short. Avoid the run-up to the end of the year, when volume rises for reasons that have nothing to do with the phones.
A mid-month week in a quieter stretch, with the cutover on a Tuesday or Wednesday, gives the practice the rest of the week to settle anything that surfaces and a weekend before the next busy Monday.
Then protect the week once chosen. The most common way a well planned migration becomes a difficult one is that the date held while everything around it moved, and the practice arrived at the cutover already dealing with something else.
Tell the whole team the date as soon as it is fixed, including clinical staff who will not touch the new system but will notice the front desk being busier than usual. A practice where only three people know a migration is happening this week is one where everybody else concludes something is wrong.
The vendor agreement, and where it stops
One question comes up on every medical implementation, so it is worth answering plainly rather than leaving it to a later conversation.
Cleod9 will sign a business associate agreement through Wildix, the platform behind the service. The agreement reaches voice, voicemail, video, recording and transcription. It does not reach SMS text messaging, which sits outside it. On the platform side, Wildix holds SOC 2 Type 1 and Type 2 audit reports and encrypts call media with DTLS-SRTP, with TLS protecting signaling and web traffic.
Where it stops is worth understanding as clearly as what it covers. The agreement governs how the vendor handles information the practice puts into the platform. It says nothing about whether the practice recorded a call it should not have, left playback open to the whole office, or discussed a patient on speaker at the front desk.
Those are the practice's decisions, and what the practice is required to do about them is a question for its own privacy officer or counsel.
Talking to Cleod9
Cleod9 is a Dallas-Fort Worth provider supporting its own customers, so a Plano practice works with someone in the same metro rather than a distant queue. The platform is described on the Cleod9 services page.
Bring the page describing how the practice actually handles calls; it is the specification and it produces a better configuration than any conversation about features. The concrete items to settle are temporary numbers for building and testing, what training is provided and when, how quickly routing can be changed if something is wrong on the day, how emergency address information is registered and verified, and what reporting the practice will have at thirty days.