Just encapsulate the content you want to show only to logged in users or or…
Migration made easy: How to copy a WordPress website to a new server but continue using the same URL
Basically WordPress migration it is not that easy as stated in the official WordPress guide. Why? Simply because just copying the website with bigger sites is just far more complicated and time-consuming than using a migration tool like WPvivid migrate.
But using this tool requires a fresh installation of WordPress which furthermore requires a working domain, which you would not have with the official method until the DNS points to the new server location.
What is the best way to copy a WordPress website?
Yes, you can simply copy a website, download everything via FTP or zip and download the whole package via ssh to the new location. But you have no chance to test everything on the new server prior to making the switch, and this as stated before is time-consuming and doesn’t feel smooth.
Pros
- does tot require an interim domain
- straight forward in terms of „no changes to DB necessary“
Cons
- No chance to test the site on the new server
- Requires technical knowledge if copying via SSH or
- Very time-consuming if copying larger sites via (s)ftp
But what are the alternatives for Website migration?
You have your source site to be migrated and a new, fresh and empty installation on the target server with an interim-domain. You install WPvivid on both instances and click on „auto migration“. On the target site you create a key which you insert in the source site. On the source site you then start the transfer.
Lean back and wait. Given that your server has enough resources after a couple of minutes, of course depending on the size ion the site, you can refresh the „restore“ page on the destination site and the received backup is ready to be restored.
Fortunately, WPvivid takes care of all the database and path changes necessary to make the restore work with the interim domain. After a couple of minutes after the restore, you can simply log in and test the site on the new server with the interimsdomain.
When everything is fine, you need to make the switch: On the interimssite, change the URL in the settings from the interimsdomain to the final domain! Beware: you won’t be able to log in the interims site any more afterwards until the DNS changes in the next step have properly propagated.
Furthermore I would recommend to make additional changes to the database to make sure all URLS have changed. You can use the following tool to generate the according statements. Or use a plugin like Blue Velvet „Moving WordPress“ instead.
If you are using Plesk on the destination server, you also need to change the domain from the interims url to the new url in the hosting settings.
/* update all post permalinks */ update 2aON9s_posts set guid = REPLACE(guid, 'https://jovial-robinson.202-61-225-116.plesk.page/', 'https://www.portofsilk.de') where guid LIKE '%https://jovial-robinson.202-61-225-116.plesk.page/%'; /* update all post content */ update 2aON9s_posts SET post_content = REPLACE(post_content, 'https://jovial-robinson.202-61-225-116.plesk.page/', 'https://www.portofsilk.de') where post_content LIKE '%https://jovial-robinson.202-61-225-116.plesk.page/%'; /* update all post meta */ update 2aON9s_postmeta SET meta_value = REPLACE(meta_value, 'https://jovial-robinson.202-61-225-116.plesk.page/', 'https://www.portofsilk.de') where meta_value LIKE '%https://jovial-robinson.202-61-225-116.plesk.page/%'; /* update all options */ update 2aON9s_options set option_value = REPLACE(option_value, 'https://jovial-robinson.202-61-225-116.plesk.page/', 'https://www.portofsilk.de') where option_value LIKE '%https://jovial-robinson.202-61-225-116.plesk.page/%';
Pro Tip: Before you make the domain switch in the settings and the DB add one single change to the front page like a dot or anything so you can distinguish the new from the old installation. This way you will know when the switch is made if you see that change under the new url!
PROS
- click and go
- you can test the installation prior to making the switch
CONS
- Requires enough resources on both the source and detonation servers for th migration tool to work properly!
- Requires an interim domain
- Making the switch requires additional changes from the interim domain to the final domain
I do prefer this second method, but must admit that still a couple of steps are necessary. Still, I like it more because you can test everything under a test domain.
Dieser Beitrag hat 0 Kommentare