At the end of July 2026 the old Windows server that had run many of our longest client relationships lost power and did not come back. It held legacy websites, SQL Server databases and years of history. This is what we did next.
First, get the data
The priority was the data, not the websites. We evacuated the SQL Server virtual machine and recovered more than 230 databases, 169 GB in all, and verified them. Two of our own products, Sdeal and Tournamental, were restored and running on new infrastructure the same day, including Sdeal's 470,000 products and 3.07 million price-history rows.
Then bring the old sites back
Seven legacy websites, built on platforms as old as ASP.NET 3.5 and nopCommerce 3.4, were running again on a new virtual machine behind a Cloudflare tunnel by 21 August. Others were moved off old technology entirely: one self-storage site went from the old Windows server to Cloudflare Pages in a single day.
Then make sure nobody finds out the hard way next time
A few weeks later a crash took ten client sites down for about two hours before anyone noticed. That was not acceptable, so we built a site monitor that checks 64 sites every two minutes and alerts a person. When our server hardware failed on 5 October, every production service was back on spare hardware the same evening.
What we learned
- Back up the data in a form you can restore elsewhere, and practise restoring it.
- Old platforms do not fail gracefully. Plan the move before the hardware decides for you.
- A monitor nobody reads is worse than no monitor. Alerts must reach a person.
If your website runs on old technology and you are not sure what would happen if the server died, our legacy website rescue service is built on exactly this experience.