The reason I reported the problem with last night’s migration here rather than as a ticket was that it seemed highly unlikely that a error with migrating the entire server would be limited to only our files.
I also figured that you would want to correct the problem with last night’s migration for the entire win32 server. Are you suggesting that rather than fix this migration problem globally, you are going to instead require all the users of win32 to each file individual trouble tickets once they discover the faulty server migration messed-up their files???
Moreover, if you do not find the cause of the migration problem now, it seems likely that this same mistake may be repeated when you migrate the other servers that hold our other client’s web sites??? ?(
they are having for about a month RAID controller issues preventing them from rebuilding RAID properly, so we’ve kept good backups and moved as soon as we could.
The performance problems we have been experiencing on-and-off with win32 have been going on a lot longer than a month. 
But even if you discovered this a month ago…Look, if we found a bad RAID controller in one of our mission-critical PC’s, it would get replaced THAT DAY. We would NOT let a bad hard disk controller fester for an entire MONTH, making backups and crossing our fingers that it didn’t crap-out on us in the meantime!
That our hosting company would do such a thing, let alone with a PC that is handling client’s web sites, distresses me more than I can put into words. :nono:
With regards to the slow performance, the web page that we were trying to view earlier did not contain ANY database code - MSSQL, MySQL or otherwise - it was virtually straight HTML. So it doesn’t seem to be limited to just database accesses.
If what you are saying is not that SQL access is slow right now, but that you migrated servers containing heavy-use SQL sites while leaving all their data in Florida, and the new servers are not beefy enough to handle the processing load caused by this migration choice, thus resulting in ridiculously slow performance for ALL users of win32???
If this is the cause, then your idea of adding extra CPU horsepower is a good one. If that doesn’t work, then I would suggest trying one of the following -
A) Try to limit the CPU load on any heavy-traffic database site on win32, so that they do not drag down everybody else’s web site; or
B) Move the heavy-traffic database site(s) to a separate server until you can rectify this; or
C) Disable the highest-traffic database sites on win32 until this problem can be resolved, as it is better to have a few clients mad at you, than every client using this server!
But you need to do SOMETHING to fix this, as the performance is so ridiculously bad as to constitute a loss of service. My God, performance of win32 was so bad as to make free hosting sites look like a superior alternative!!! 8o We have a meeting with our largest client late today to show-off our latest progress, and I shudder to think how they will react if win32 is anything like it was this morning!
UPDATE ON MIGRATION PROBLEM - Testing has revealed that attempts to programmically update or write to migrated win32 local database files by ASP web pages are ALSO broken post-migration. When an ASP program attempts to update a local database, the web page blows-up with an error, stating that the database is read-only.
Hmm…I’m wondering if a tech changed all the server user files and/or web directories to Read-Only (for the same reason they also disabled ftp access - to prevent file changes during final file sync), and then forgot to change them back after file sync was completed???
That might be a good starting-point for diagnosing the cause of this server migration error - both to correct it, and also to prevent it from happening again when you migrate the other servers.