Moving a website to a new backend database

I recently worked on a project that moved a gargantuan website to a new web host that came with a new backend database. Here I will run through a few pointers I picked up along the way.

Prepare for a new mindset

It’s difficult to mentally prepare for a new way of updating your website. For example, if you are moving a blog that has always been on WordPress, and then you moved it to a new blogging platform, the content management system that you use to type your blog posts will be different. It will look different than WordPress, and it will behave differently too. Try to think through your new workflow as best you can before making the move. Become familiar with the new host’s tools and test as much as possible.

Prepare others as well

If you have more than one individual updating your website, you need to manage their expectations too. Sure, the new CMS might have more features and functionality, but it will also be a different experience and have a few drawbacks. Don’t promise a full moon and then only deliver a waning crescent. Ensure the expectations of your group are realistic and prep them for the downsides as well as the up.

Accept certain fates

During the project I mentioned earlier, we moved tens of thousands of files to a new database. For this project, that meant all our old and trusted URLs were now broken. The new database named files differently, and our old file paths no longer worked. This was extraordinarily frustrating to me because I kept thinking of the end user’s bookmarks that were now useless. I kept thinking of our new URLs that were an ugly combination of question marks, numbers, and gobbledy gook that the new database spit out as opposed to our clean FTP file paths we created ourselves. I was not happy. I pouted about it for a day then decided to accept the URL fate. It was happening whether I liked it or not.

We opted to redirect some popular URLs to the new gobbledy gook ones so that any bookmarks would still work, but we understood that doing this for 10,000+ files was unrealistic in our time frame. Once I accepted the new URLs, I honestly haven’t been bothered by them since. Seriously. It’s like I simply…gave in (which is not my style, trust me).

Give yourself AMPLE time to make the move

Think of how long it will take you to get everything moved over to the new database and make it look pretty. Multiply that number by two, then add a week, and that’s the amount of time you need to ensure your site makes the transition in a cordial way.

WYSI-NOT-WYG

Literally. What you see is NOT what you get.

I feel like there were very few files that transitioned nicely to the new database. Most pages looked wonky with extra paragraph spaces, images that didn’t move over, etc. OH – not to mention that EVERY internal link was now null and void thanks to the URL differences. Moly, it seriously was a mind job.

Please keep in mind that moving your files over to a new database will result in unexpected changes with your HTML and styling. You’ll have to check every page you move to ensure it looks the way you want.

Be prepared for negative feedback

Users will let you know very quickly what they think. The good, the bad, and the downright ugly. Keep a thick skin, respond to feedback appropriately and graciously, and please please please remember that you will not please everyone. Some people are just perpetual grumps.

 

Leave a Reply

Your email address will not be published. Required fields are marked *