I dealt with an interesting case this week, which made me think about best practise for choosing the names of X3 folders on customers servers (maybe I'm just weird like that!)
We're migrating a V6 instance to a new server running V12. There was some pre-migration steps needed on the source server to upgrade V6 to the minimum patch level, so this was done by copying the LIVE folder to a folder called UPGRADE (a very sensible name of course) which was then upgraded before then exporting across to the V12 server. The V12 server is going to become the live server at cut-over. The interesting part is that on the target instance, for the first test migration the folder was called "COMPANYLIVE" (where COMPANY is the company name) because this is the name to be used for the live data folder once the system is cut-over to V12.
What is my objection to this ? Well it's all down to risk...
The first issue is that you are not necessarily practising your live migration. The case raised was because when the same process was undertaken on the live migration cut-over weekend, the folder validation failed and the migration ended up being abandoned. The root cause was due to not removing all objects relating to the first (test) migration of the COMPANYLIVE folder from SQL server. If you want to use the same folder name for test migration and live migration, to fully test the live cut-over you need to do the test migration, drop the live folder, then redo the test migration again. Otherwise you do not know if your tidying up process works.
My second thought is that why not call a folder used for the test migration something like "TEST" or "MIG" or "UAT" Then when you come to do the live migration, call the live folder something like "LIVE"; it just seems logical and clear to me with no chance of confusion. The only things I can think of which would prevent such a simplistic approach is (a) you have multiple live data folders or (b) you have some external interfaces which can only be integrated to the (soon to be) live server name and the live folder name, although in this case you really need to worry about how are you going to perform testing after go-live!
As an aside, I have also seen on customer systems live folders called "TEST" (and test folders called "LIVE") which is a big no-no in my opinion (Why would you do that!) OK it doesn't matter to the users, as the endpoint descriptions can refect the intended use, but as an implementor or if you're troubleshooting a problem after go-live, you don't want to have misleading folder names as mistakes can easily happen.
The final consideration I can think of is that archive folders have an "H" prefix added, so might be best to avoid using folder names starting with "H" Oh and don't forget that the folder name is maximum of 10 characters, so don't use more than 9 to allow for the extra characters in archive folder names.
In conclusion, I would suggest best practise is to take some time at the begining of a project to think about folder names. Keep them as simple and short as possible, but their use must also be easily identifiable.
Your feedback is welcomed, feel free to share your experiences, thoughts, comments or criticism