Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

thomthom's avatar

How to migrate to a new droplet?

I got a server on Forge, with three sites running on a DigitalOcean droplet. I have three MySQL databases, one for each site. Ottomatik backs up database and a few files which have been uploaded via the apps. It's also running an older Ubuntu version.

It's an older PHP 5.6 config which doesn't offer and automatic upgrade via Forge.

I was thinking I might as well create a new droplet and migrate the sites.

However, I've not done this before, so I'd like to seek some advice on what to do and in what order in order to ensure a smooth transfer.

Is Ottomatik possible to use as a method of transfering data? Databases and files? Of will I have to manually migrate database and files?

(I'm somewhat concerned that different MySQL versions might cause database migration issues.)

Any ideas, suggestions, tips? (I'm a linux noob.)

0 likes
2 replies
cmgmyr's avatar

Short answer is that you'll have to migrate everything over by hand - domains, settings, files, database, ssl, etc

For the database version changes, I did run into some issues trying to port over structure and data "as-is". What I ended up doing is setting up a new database, running the app migrations, then porting the data over (I used Navicat). This way the new DB structure would be up to date with the newer version of MySQL.

Once your new sites are back up and running you can point Ottomatik to your new server. I haven't used them myself, so I'm unsure of the process.

thomthom's avatar

Thanks for the feedback.

I just remembered that I also have BugSnag set up. I realize I should have documented my site better as I was developing it.

I guess my strategy will be to set up a new droplet, with a temporary subdomain where I test the required transfer steps.

As for doing the actual switch, when I have a working verified workflow, would something like this work:

  1. Change TTL for my domains to something very low.
  2. Wait for that to propagate throughout the interweb.
  3. Take down the production sites in maintenance state (artisan down)
  4. Copy files
  5. Migrate DB via Navicat
  6. artisan up

Missing anything there?

This of course assumes that I provisioned the new site with all the necessary config.

One thing I encountered on a previous non-Laravel site migration was that some DB date fields where not valid at the target DB. So I had to dump the DB as .sql files and manually tweak them. (I think it was an issue with NULL vs zero-dates). That's something I could test out and setup an automated script, so when I take the production site down and dump the DB I have everything ready for as speedy conversion as possible.)

Talking out loud for a bit here - just to see if it sounds sane of whether I missed some key steps.

Please or to participate in this conversation.