Work/Kinsta Migration

Moving 180 healthcare sites off 267 aging servers cut downtime per site by 94%

Jimmy Tran · 2026 · 4 min read

Outages before and after the Kinsta migration

EOS Healthcare Marketing runs websites for about 200 dental, veterinary and medical practices. At the start of 2026 those sites ran on at least 267 DigitalOcean servers, and in one 30-day stretch they went down 2,024 times. Starting in late June, I moved them to Kinsta in batches. On the sites that moved, downtime fell from 4.6 hours a month to 17 minutes.

Company
EOS Healthcare Marketing
Role
Lead developer
Timeline
Jun to Sep 2026
Stack
Kinsta, Cloudflare, UptimeRobot

Kinsta Migration at a glance

  • Downtime per migrated site fell from 4.6 hours a month to 17 minutes
  • 58% of migrated sites logged zero incidents after cutover
  • Server response got 4.2x faster, from 107ms to 25ms

One server per site, and most of them tired

Each practice site had its own droplet, managed through ServerPilot. That meant 267 separate machines to keep patched and monitored. Going through the inventory turned up the same problems over and over.

  1. 01

    Outdated servers

    Some boxes were 6 to 7 years old and still on Ubuntu 18.04, which stopped getting standard security updates in 2023.

  2. 02

    Old PHP

    42% of the apps in the hosting inventory ran a PHP version that no longer gets security fixes.

  3. 03

    Constant crashes

    Most sites lived on 1 to 2 GB droplets with no headroom. One sat at 93% memory with power cycles days apart. Nearly every outage was a connection timeout, the signature of an overloaded server.

  4. 04

    Slow sites

    Overloaded servers meant slow responses. On one batch, server response averaged 107ms before the move.

  5. 05

    Bot traffic

    Bots hit the sites constantly, and with no firewall in front of the servers, every droplet absorbed that traffic on its own.

Measuring before moving anything

Before the first site moved, I set up a way to measure the result. On the morning of each batch's cutover I captured uptime, incidents and response times from UptimeRobot, plus PageSpeed scores from Google's API. Thirty days later I pulled the same numbers from the same monitors over a window of the same length.

The goal for the project was a 25% drop in outages.

Moving 180 sites without anyone noticing

Sites moved in batches. Each one was built and checked on a temporary Kinsta URL before DNS changed, so visitors kept reaching the old server until the new copy was ready. Every batch kept a 7-day rollback window in case something surfaced after cutover. None of the cutovers caused downtime that visitors could see.

On Kinsta, each site sits behind a server-level firewall with DDoS protection and malware scanning. PHP is current, and the host patches the operating system, which takes care of the two oldest problems on the list above.

What changed

94%

less downtime per site

4.6 hrs a month down to 17 min

58%

of migrated sites

had zero incidents after cutover

4.2x

faster server response

107ms to 25ms on a 10-site batch

200+

servers retired

267 droplets down to about 50

Outage incidents per month, all monitored EOS sites

First batches live Jun 29AprMay1,837JunJulAug186Sep
Outage incidents per month, all monitored EOS sites
Monthincidents
Apr1397
May1771
Jun1837
Jul547
Aug226
Sep186
UptimeRobot incident export, April to September 2026. Response-time warnings excluded.

The number of sites that went down at all fell with it. In June, 158 monitored sites logged at least one outage. In September it was 18, and about a third of September's incidents came from a single site that has since left.

Once a site got past its first 48 hours on Kinsta, it stayed up. Across the 118 migrated sites in the first study, steady-state downtime added up to about 1.4 hours in total.

The fleet-wide count moved too. Across the same 189 monitored sites and two 30-day windows, outages dropped from 2,024 to 306, an 85% cut, even though that count still included sites waiting to migrate. One site that had been down since August 4 made up much of the remaining downtime.

Chart indexing each before number to 100 to show the drop
Fleet-wide, with each before number set to 100. Outages fell to 15.

Next case study

Maintenance, Fixed →

Updates happened when someone remembered. I built a routine around one dashboard and AI, and critical vulnerabilities went from 99 to zero.

Work with me

Have a fleet of sites that needs this? Let's talk.

jimmytran935@gmail.com