Chris is spot on (+5 C.D.), the most important thing here is that you make yourself aware of all of the dependencies related to changing your abbreviated dialing solution. Especially if you went the path of programming station lines, etc. with the abbreviated numbers (vs. a normalized or globalized strategy).
Chris' list is pretty comprehensive on where you should look to prepare for a change like this. The process or tactics you use to execute the changes depends on various factors. The most important factor being the comfort level of your staff, yourself, or your consultant (whichever one applies). The change is tricky. It would be most ideal to leverage a resource that has experience navigating these changes to avoid negative service impact.
From a CUCM perspectice, you could use BAT export/import. This method may be more "approachable" for someone who isn't comfy under the hood of the CUCM. However, it is a bit "bloated" from a process perspective and you will be doing some clean up.
Yes, it is true you can also use SQL to tackle this change. This can be a more streamlined approach but comes with a fair amount of risk for the uninitiated. Whenever I have to make broad changes in CUCM I use SQL. With proper application, it is a good tool for making sweeping changes quickly and with minimal (if any) impact to other aspects of your call processing. However, I can't stress enough how improper application can screw up a lot of things. Also, there are few people that know the ins and outs of the DB. I know because I have behind a few folks who meant well but executed poorly.
My recommendation to colleagues who are tackling this type of change goes the path that Chris has forshadowed:
1. Prepare: Make sure you understand all of the moving parts in your entire solution (not just UCM and not just station DNs). Again, Chris' off the cuff list is a great start for info gathering.
2. Plan: This starts with a strategy. Go via BAT or via SQL. If you don't have the experience in-house and can't or don't want to hire someone who does, then you might be better off going the BAT path. SQL is cleaner when you know what you are doing but a disaster if you don't (or don't have a way to test, see #3). Once you pick your strategy, then map out the plan details. Map out every step of execution as well as a roll back strategy if you happen to screw something up.
3. Practice: If you have a lower environment for testing (e.g. a lab or lower environment production system) then you are in a great position. If you don't then you may want to stand up a vm environment just to test out your process on UCM. Yes, testing all systems is ideal but most of the meat is in UCM and if you can test on a VM then that is better than nothing. The point of practicing is to gain confidence and reduce risk.
If you (or one of your teammates) are comfy with SQL then you may find some useful information here:
http://www.ucguerrilla.com/search/label/CUCM%20SQL%20Query
I have some blog entries that cover most of what you would need to look at but only one or two actually tackle the question of doing bulk updates. So, it may be a good way to get ideas but only if you are inclined to go that path and have some comfort with SQL databases.
HTH
-Bill (http://ucguerrilla.com)
