… starting from the point where the story stopped.
We are happy to inform you about your account(s) upcoming switch from cPanel to our new control panel – Site Tools.The SiteGround Team
In addition to the email (see part 7), there was an
Important Notifications in the Home tab of the New Client Area:
SCHEDULED SWITCH FROM CPANEL TO SITE TOOLS.
The server hosting your account [OBFUSCATED] is scheduled for a switch from cPanel to Site Tools on Jan. 12, 2021.
When I clicked on CHECK REPORT (next to the above notification), a popup window informed me about the migration with further precautionary advices:
To avoid account configuration discrepancies after the switch, we may have to block your access to the cPanel of those accounts. If it is needed, the block to cPanel will be imposed 24 hours before the migration date. During that time your websites will be accessible, and you will be able to perform web management tasks that do not require cPanel access. For example, you will be able to update any WordPress site through its wp-admin interface as usual.
At the date of the migration there might be a short service interruption, affecting your website and email availability. We try to schedule the migrations outside the standard active business hours, so your sites’ traffic is affected as little as possible.
After the migration you will find all your websites under the Websites section. Each of your sites will have a link to its own Site Tools – this is a set of tools, replacing the cPanel control panel. Site Tools are extremely intuitive, and you will be able to find all the needed functionality in them. However, if you are wondering how to execute a specific task you used to do in cPanel, we have prepared a list of articles featuring how things are done in Site Tools in comparison to cPanel: https://my.siteground.com/support/kb/category/site-tools-vs-cpanel
Straightforward message indeed! The time for the so-dreaded migration has come!
48 hours before
To be on the safe side, I thought of doing a backup1 just before the migration. Don’t forget that one of my main concern is whether SiteGround (or to be more specific their automated script) will be able to handle my peculiar WordPress Multisite configuration (i.e. no wildcard subdomain). Given the above message, I decided to proceed with my backup 48 hours before the actual date. However, when I tried to access my account…
Migration from cPanel to Site Tools is In Progress
Your hosting account [OBFUSCATED] is scheduled for migration from cPanel to Site Tools on January 12, 2021. To minimize the possible configuration discrepancies after the switch we need to block your access to cPanel 48 hours before the migration and kindly ask you to avoid making changes on your website until the switch is complete if possible. During this time we will migrate the data, synchronise it and run health checks on all websites to verify that they operate normally in the new environment before switching to the new control panel officially.
Please note that even though your access to cPanel is blocked, your sites remain fully accessible, including any backend admin functionality so you can keep performing your normal web maintenance.
“No, I cannot perform my normal web maintenance!”
I was clearly not happy with this unexpected change (48 hours instead of 24 hours). I could not do my backup and there was nothing left but hope that the migration will go smoothly…
January 12, 2021
Although I was not actually monitoring my websites during the migration, I can tell something must have gone wrong with my blog (i.e. this site). Specifically, unlike my website that was fine, my blog (subdomain) remained inaccessible for a longer period (than the anticipated 20-40 minutes downtime). Instead of my #253F8C blue (see Which header media for this blog?), I was welcomed with SiteGround ‘under construction’ page:
When I accessed my Client Area and clicked on CHECK REPORT (next to the “Important Notifications”), the progress report was updated with this message:
We have initiated the switch to our new Site Tools setup. It is expected for the affected web services like website, email, etc. to be inaccessible during the next 20 to 40 minutes. We are grateful for your patience and we kindly ask you to not report site down or other related issues about the affected account until the procedure is over.
Fortunately, the ‘under construction’ page was eventually replaced with my blog, and I received later that day an email informing me about the completed migration.
The migration from cPanel to Site Tools has been completed. Now you will be able to manage your hosting with our new Site Tools and enjoy many performance and management improvements that result from the change.The SiteGround Team
Completed, granted. But was it successful?
Why did SiteGround use the term
completed this very time? From the subject of the email –
Switch from cPanel to Site Tools completed – to the text on their graphics –
Switch to Site Tools completed – to the content of the email, the word
successfully was nowhere to be found! There were some
Quick Tips for Using Site Tools, but no claim of a successful switch. Instead, there was this recommendation:
What to Check After The Migration
We strongly recommend that you check your website, emails, FTP accounts, SSH accounts cron jobs or any other specific functionality you may have used. For standard cPanel configurations no issues are expected after the transfer. However, this is a highly complicated process and there sometimes might be issues with custom setups. If you detect any issue, please check the list of recommended fixes you may apply in the Post Migration category of our Knowledge Base.
Let me first address a question that was not answered by Hristo (when I posted my comment to their initial blog post on the New Client Area and Site Tools):
How your ‘Site-Centric Philosophy’ will display my different sites knowing they are all within the document root (i.e. no separate document root for my subdomains)?
Although I found my answer – after the first step of the migration (see part 5) – in the Website tab (of my Client Area), with only one account listed indeed, I thought that the second step of the migration might have changed that fact. It didn’t.
However, with the second step now
completed, I noticed a difference (as compared to what I described in part 5). In particular, the previously empty Added Extras section was no more displaying
Nothing here yet. Instead, I could find the Let’s Encrypt SSL certificates for my website and my blog (i.e. subdomain). I was very glad to have the information about their status back2.
As for the handling of my WordPress Multisite configuration, it seems that SiteGround automated script managed it well. I could not find a clear information about the number of subdomain(s), though (as opposed to the previous display in cPanel on the left under STATS). That being said, under the Domain > Subdomains menu (on the left in Site Tools), I could find my subdomain blog.cogitacive.com correctly listed. In other words, they (SiteGround script or technical support) didn’t force the use of a wildcard subdomain; yet, they listed the latter in the same table as my existing subdomain. I was happy to see that the toggle next to it was however grey – as in OFF!
To make sure that even non-existing subdomains open your main site and you don’t lose traffic, you can enable Wildcard through the toggle next to the *.yourdomain.com entry in the table below.
To be continued…
1 A double backup, actually! Indeed what would be the point of doing my typical Softaculous backup if SiteGround remove Softaculous, hence, my capacity to restore this backup? Thus, I did a manual backup (see Backup, Backup, Backup!) of the files (using File Manager) and of the database (using phpMyAdmin) – the last two FREE options that are supposed to remain after the migration. ^
2 As complained about in SiteGround New Client Area and Site Tools – part 5, it was nowhere to be found in the New Client Area; at least before the completion of the second step. I was without this useful information for 9 months – an eternity when you think how things can go wrong (see Making my website work over HTTPS – the proper way). ^