Article summary
Launching a rewrite of an existing public-facing website is an exciting, yet tricky process. It’s exciting because you know that you’re working on a well-tested and market-validated idea. You already have users—something that new companies and products need to work hard to obtain.
While this is great, these users also complicate things. You need to guard their user experience every step of the way. Can they still do what they need to do? Can they figure out how things work on the new site?
Pre-Launch Considerations
Here are some things to think about before the launch begins.
Data migration
You most likely have some data to migrate from your old website to the new one. You’ll need a plan for this migration. Understand how this data is created on the old site so you don’t miss migrating any of it when you switch over. This can be very tricky if you plan an immediate switch.
Links and redirects
Ask yourself if all of the old URLs and links still work on the new site. Users may have some of them bookmarked. You probably want to have your new site accept these old URLs and redirect users to the appropriate pages on the new site.
Feature comparison
If the new site didn’t bring along some features from the old one, users may look for them and be confused. It’s a good idea to have a plan to communicate these situations to users–preferably ahead of time if features are being retired. If you launched with some features that aren’t yet completed, it may be worth letting users know that they will be coming out in the near future.
Deployment process
You will have users the second you turn on the new site. It’s important to understand your deployment process as you may need to deploy updates/bug fixes shortly after going live. Will it result in downtime for users? If so, how much? It’s also good to consider caching times if you need to deploy an update. Are any of your assets being cached, and if so, how long?
Maintenance process
If you need to bring your new site down for an extended amount of time (longer than just deploying an update), make sure you have a plan for this. How do you want to communicate this to your users? Do you want to display a placeholder or maintenance page while it’s down?
External dependencies
Are there any third parties that were dependent on the old website? Perhaps it exposed an RSS feed, or an API? Will these users continue to be supported when the new site launches?
Logging and alerts
When you launch, it is critical to have a good logging and alert system set up. It’s OK to be a little verbose with your logs at launch and then scale back after things are working well and have stabilized. You don’t want to end up in a situation where something is going wrong and you don’t have enough technical insight to diagnose it.
Pre-Launch Performance Testing
One interesting aspect of launching a rewrite for a public website is that you have historical traffic data. This can be a huge help. However, you have to be careful when analyzing and using it to prepare for the launch of the new site.
The first thing to consider is what it is measuring. For example, is it measuring the number of users, user sessions, web requests, etc.?
It can be hard to generalize from lower-level metrics like web requests. It’s likely that the new website architecture and technology may be quite different than the old one. Having access to the old codebase or knowledge of the architecture can be really helpful in this situation.
Higher-level metrics like users or user sessions might be more helpful, but they, too, have some caveats. It’s likely that the user workflows on the new site may be different.
Mid-level data like per-page view counts can also be valuable. Of course, the pages may not map one-to-one from the old site to the new. Regardless, page accesses on the old site should be a decent feature-level traffic predictor.
Having this historical data is definitely useful. It’s just important to be aware that you won’t be looking at apples-to-apples comparisons. The best predictor for access patterns on the new site is seeing access patterns on the new site.
If you are able to do some pre-launch performance testing, you should strongly consider it. We have used services like Blazemeter to do this. These tools usually record API activity that results from using your website, and then they replay the activity at varying volume levels to measure how your website responds.
Summary
If you are able to slowly roll users from the old site onto the new one, you should consider doing so. Planning an immediate switchover can be difficult, but hopefully some of the approaches above will help you plan and facilitate a smooth launch.