• we have a website hosted with DO for the past 7 years and in those 7 years we did exactly 0 updates to Ubuntu, Apache, php, …
  • at this point we are running Ubuntu 14, php 5.6, … and we would like to update everything (to Ubuntu 20, php at least 7.4, …)

We figure to best way to update everything right now would be to create a new Droplet from scratch, set it up, migrate the files there, test everything out and when ready - “somehow” switch the current Droplet with the new one.

Here’s the idea we have so far and I’d like to know if this is doable or not:

  • 1-click install a new Droplet
  • migrate files to new Droplet but keep DB pointed to the old (current) one
  • test everything out on the new Droplet
  • once ready, put everything in maintenance mode and migrate the DB to the new Droplet
  • (and here’s the crucial part) repoint users to this new Droplet – how would we do this?

Since we already have everything we need in our account - could we just go to => Networking > Domains and repoint the IPs from the old Droplet to the new one? Would this work? Would this need time to propagate or would it be immediate? I’m guessing we’d need to rekey the SSL certificates after we’re done?


These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
1 answer

Hi @williamd991e9db2513f2cfb1c,

As I can see you’ve got it 90% figured out, great plan by the way!

Here is how I’ll do it as I see it as the easiest. It’s mostly the same as your plan but with small different details.

  1. First, as usual, create the new droplet
  2. Install all the necessary software on it (Apache, MySQL, Nginx etc.)
  3. Once you’ve installed all that you need on it, migrate(transfer over) your application to the new droplet but DO NOT change the A records to point to the new droplet
  4. Use hosts files to test your application on the new Droplet.
  5. Once you confirm everything is correct, do a last rsync from the old to the new droplet to sync any changes done to the live application while you were testing it on the new droplet.
  6. Right after the rsync finishes, change the DNS settings from the old to the new droplet.
  7. Wait about 24 hours for the DNS to propagate and the domain to start fully working from the new droplet
  8. Turn off the old droplet.

That’s it, your application/s would be working from the new droplet now without a problem.


  • Thank you very much for your response, it’s been very helpful!

    We’re currently at step #4, hoping to complete the migration next week.
    Couple of more questions =>

    • DNS propagation can be shortened by creating an Apache Proxy on the initial Droplet, correct?
    • how do we migrate the SSL certificate? the certificate itself is linked with a domain, not the server - correct? so in theory, we should simply copy the certificate we currently have on the old Droplet to the new one, set it up in Apache and it should continue to work properly? Thanks!
    • Hi @williamd991e9db2513f2cfb1c,

      So first, on the DNS side of things, I haven’t heard of such a way. In these days, DNS propagation is really fast so I don’t think it would be necessary. If you are concerned about data loss, you can always put a maintenance window for one or two hours until the DNS propagates.

      The second one, about the SSL. Yes, the SSL is actually 3 files. The certificate, it’s key and it’s cabundle. What you can do is, get the files from the server. You can see where these files are stored from your Apache or Nginx domain.conf file. Having said that, if you are using a free SSL Let’s Encrypt certificate, you can just use certbot to re-issue it on the new host!

  • And a sub-question =>

    • since the domain is already pointed to (for the old Droplet), the propagation itself should be faster considering we’re only “repointing it” to a different Droplet (IP) on this exact same nameserver? Thanks!
    • Hi @williamd991e9db2513f2cfb1c,

      It shouldn’t have that much of a difference, to be honest. I’ve found the DNS changes actually sometimes a little bit longer when done on the same Nameserver unless you set the TTL to a lower number like 360 rather than the default 3600.