One of the issues that we’ve encountered several times with acquiring websites is difficulties with the existing technical structure of the site. It’s not uncommon for people to lose interest in things like routine maintenance, software upgrades or making improvements in the time leading up to their decision to sell a website. As such, it’s fairly common for things to be in less than tiptop shape when we take over. Sometimes we’ve had sites with significant problems that affected the intended functionality of the site, other times we’ve had sites that worked but were less than optimal from either a current user experience standpoint or a long term maintenance perspective.
While we try to operate things as-is when possible there are risks to doing so. For example, sometimes the software that the website depends on has been abandoned by its original author and no longer receives security updates or bug fixes. Other times, the site has evolved from uncertain specifications in a way that does not follow software development best practices such as the DRY principle (do not repeat yourself), causing any required updates to need to be made in several different places. Sometimes things are functional but simply offer a poor and inefficient user experience that makes certain tasks very time consuming.
Here are a few things we’ve learned along the way.
- Don’t throw everything out and start from scratch if you can avoid it. If you don’t plan a migration well, you may lose lots of organic traffic from search engines who have your existing site structure indexed and cataloged. You may also lose the benefit of deep links from third parties to your existing site. You risk alienating return visitors/customers with a website that operates significantly differently from what they were used to. We’ve seen a website that used to make ~30,000 USD in sales drop to less than 1,000 USD a month in sales largely because of a poorly planned migration from Magento to BigCommerce that was very time consuming, caused significant downtime and had a significant negative SEO impact.
- Look for quick wins, fix what you can easily fix. Some issues are easier than others to resolve. Perhaps there are poor page load times that could be improved with a CDN. Perhaps there are some minor problems preventing the website from being mobile compatible. Perhaps a change in server configuration can improve browser caching, or, perhaps images or other assets can be better compressed or minified to reduce the size of pages. Collectively, these quick wins can add up.
- Sometimes, the performance problem can be addressed by migrating the server without changing the application. The longer a site has been running, the more likely it’s operating on old hardware or a less than optimal configuration. Things such as SSD-backed servers are dramatically more common now than they were, say, 5 years ago and can offer significant performance gains. You may not even have to change hosting providers to do this.
- Sometimes newer technologies can help without requiring application changes. We’ve seen the introduction of HAProxy increase performance 10 to 100 times over the base rate.
- Consider whether or not it’s worth improving the application. Just because something is legacy software doesn’t mean it can’t serve business needs. Existing customers may be fine with things how they are now. If things are stable or declining very slowly but are largely passive and don’t require significant effort to maintain then, well, things could be worse.
- Technical debt adds up. If you do have to rewrite, and have a big project, try not to rewrite everything at once if you can avoid it. Generally, the sooner you can get some of the performance and improved maintenance gains the better. If your application is split into several parts, focus on one part at a time. For example, we acquired an eCommerce site where the shopping cart was separate from product pages/details. In this case, it made it easy to separate the two and have the shopping cart itself improved for performance and mobile user experience while the product pages/details could be migrated later.
While trying to phase in a rewritten version of a site, there will be a time when it’s desirable to run both versions at once. There are a few ways to do this that are platform dependent (for example, if you’re migrating from one PHP framework to another you may have different base directories served by different frameworks, e.g. route some things to index.php others to index-old.php). This is also potentially a good place to use Docker in combination with an nginx reverse proxy (or potentially other reverse proxy). If you’re doing everything on one server, you can setup Docker to have containers for each of your applications (the legacy one and the new one) as well as an nginx reverse proxy. The reverse proxy can be configured to proxy requests for the parts of the site that are ready to the new platform and everything else to the old platform. This allows you to migrate easily even in the case of differing underlying technologies. For example, you may not be able to run a PHP app and a Python app on the same server configuration within the same hostname; but, with a reverse proxy handling requests it could easily pass some requests to a PHP app running on a webserver on a different port on the server and other requests to the Python app on a separate webserver and port. The nginx reverse proxy allows you to use regular expressions to pattern match locations. For example, if you’ve migrated say a blog located at example.com/blog you can use nginx to reverse proxy any requests starting with /blog to your new platform while other parts of the site would be reverse proxied to the legacy app. You can also use this technique when the apps are running on separate servers, potentially even with different operating systems or different hosting providers.