Deploying tips (having old and new website up simultaneously for data migration)

Hey all,
I’ve uploaded a website I made with Kirby to my client’s hosting. I have made a new folder and placed the website there so that the new website is a subdomain of the old website and then when it’s done, I can just delete the old website and move the new one to the default folder. However, the amount of URL changes that seem to be necessary for this switch is piling up. Is there a way to work around this and have some sort of DNS redirection prevent these issues?

Thx in advance.

You could include a list of redirects in your server config or .htaccess. Use wildcards where appropriate.

There are many different strategies you could try. Kirby sites are very portable, so depending on your server setup, how large the site is, and how tolerant the client is with a little downtime, you could simply (S)FTP into the site directory, delete the old site and upload the new one in its place. If you decide to do this, it’s always best to do a full copy of the old site first to your local computer, so if something goes wrong, you can always re-upload the old site back there.

Another strategy is to have 2 separate sites running simultaneously - a ‘new’ site and the ‘old’ site - and then just change the appropriate DNS records when the time comes to launch. For example: let’s say that the old site is ‘old.example.com’, which can be reached at IP address ‘192.168.0.1’. While you are developing the new site, you set it up as “new.example.com”, which can be reached at “192.168.0.2” (whatever IP address your hosting company gave you for your new site or VPS). That means, that while you are developing the site, you’ll have both versions available, with 2 different DNS ‘A’ records. Now, when the new site is ready, you just need to change the change the ‘A’ record of ‘old.example.com’ to point to 192.168.0.2 (the IP address of the new site), and then delete the ‘A’ record for ‘new.example.com’. This strategy is more complex, and requires a little more technical knowledge on your side, but is useful if you’re dealing with sites that require little-to-no downtime.

I hope this helps!