Changing Web Host in Morocco: The No-Downtime Method

Changing host involves two hosting accounts that can perfectly well run at the same time. Nothing forces you to switch one off to switch the other on: the source keeps serving the site while the destination is built, filled and tested. The only switch is DNS — and it does not flip all at once.

That is where the real risk comes from, and it is not a blank page. During the window in which resolvers do not all hold the same answer, some of your visitors still reach the old server and others the new one. Both display the site. But an order placed, a form submitted, an article published or an e-mail received on the wrong side exists only on that side — and disappears the day you shut the old hosting down. The downtime people fear is visible; the one that costs money is not.

Every DNS record carries a lifetime — its TTL. Resolvers cache the answer for that long and do not come back for it any sooner. As long as the current TTL has not expired, your new address does not exist for them, whatever your zone says.

Hence the only rule that matters, and the most common mistake: the TTL is lowered beforehand, and it must be lowered at least one old-TTL period before the switch. That is what it takes for every cache to have had the chance to re-read the record and learn the new, short value. Lowering the TTL at the moment you switch achieves nothing: at that instant, resolvers are still serving the answer cached under the old lifetime.

One special case is worth spotting early: if your DNS zone is hosted with the provider you are leaving, changing name servers is itself subject to the same mechanism, and it carries everything else with it. Moving the zone first, separately, avoids stacking two propagations on the same day.

Once the switch is done and everything checked, raise the TTL again: in steady state, a short TTL multiplies queries for nothing.

A site is a frozen object you copy; a mailbox is a living one that keeps receiving while you copy it. That is the whole difference, and that is where most migrations lose data.

The sequence that holds: synchronise the mailboxes to the destination a first time, switch the MX records, let the old server keep receiving whatever still reaches it, then run a second synchronisation before shutting down. A source mail account is never deleted while it is still receiving something — and it keeps receiving long after the site itself has switched over.

Two details look like failures without being any. First, the mail clients on your machines keep the old hosting's incoming and outgoing servers in their configuration: until they are reconfigured, they collect from the old mailbox, not the new one. Second, mail authentication — SPF, DKIM, DMARC — lives in the DNS zone, not in the mailbox: changing sending server without carrying those records over sends perfectly legitimate mail to the junk folder. They are recreated with the new server's values, and verified before the old one is shut down.

Two operations are often confused: moving the hosting (files, database, e-mail) and transferring the domain name to another registrar. They are independent. You can change host while leaving the domain where it is and transfer it only afterwards — that is in fact the safer order, since it avoids moving two things on the same day.

For a .ma, the transfer follows the rules of the national registry, run by the ANRT, Morocco's national telecommunications regulator. Only the providers it accredits may operate directly on that registry; the others go through an intermediary. MEGALOGI, the publisher of the platform, is among those accredited providers.

Three technical conditions must be met before filing the request: the domain must have been active for at least 60 days, its transfer lock must have been lifted with the current provider, and the authorisation code (EPP) must have been given to you. To which is added a document that generic extensions do not systematically require: the registry asks for a copy of the registrant's identity document — national ID card, passport or residence permit for an individual, a company document (ICE or RC) for a business.

Two checks are worth making beforehand, not afterwards. Who the declared registrant is: if it is your current provider and not you, the transfer depends on their agreement, and that is no longer a technical question. And where the DNS zone is actually served: changing registrar does not copy over the contents of a zone hosted with the provider you are leaving.

Changing host does not only move files: it also changes the accounting document you receive at every renewal. An invoice issued outside Morocco, in a foreign currency, with no Moroccan VAT and no Moroccan legal identifiers, is not the same document as a Moroccan invoice — and the difference shows up in the books, not on screen.

Three lines change concretely. The currency your account is debited in: billed in dirhams, there is neither an exchange rate applied by your bank nor the fees that come with it. VAT, which appears on the invoice at 20% — the site's amounts being shown tax exclusive (VAT excluded). And the issuer: a Moroccan invoice carries the IF, ICE and RC of the company issuing it, which is what your accounting expects. Settlement is by Bank card — CMI, PayPal and Bank transfer.

One organisational point avoids an unpleasant surprise: the overlap period has a cost. For as long as both hosting accounts run, both are billed. That is not a risk, it is a line to plan for — and it is the real price of the method. Better to line the cancellation of the old contract up with a renewal date than with the middle of a cycle.

One last point, stated plainly rather than guessed at: our data centres are in Europe. Changing provider moves an invoice, a contractual relationship and a control panel — not the geographical position of your servers.