I have had a website for a long time and my emails associated with MXPlan. OVH informed me that they were performing a “migration of emails to Zimbra” on Friday July 10, assuring me that I would have “nothing to do”. However, since then I have been unable to access my emails, neither through my client (Apple Mail) nor through the Webmail, which has become inaccessible: https://webmail.mail.ovh.net/ returns a 500 error and https://zimbra1.mail.ovh.net/ does not recognise my address + password. Changing the password changes nothing. This issue doesn’t even appear to be covered by the OVH documentation.
It’s incomprehensible, and it’s my professional email, so it’s catastrophic. All of this on the eve of a four‑day weekend with customer support and even an unreachable chat… No comment. Do you have any idea what I can do??
Hello @Gaston
Thank you for your message. Indeed I had opened a ticket and just managed to reach someone; they’re trying to figure out where the problem might be coming from. Stay tuned.
The process is designed to be automatic and without client intervention, but as with any migration, problems can sometimes arise
When a migration ends up "half‑way", OVHcloud support is the one who can check the actual state of your account and force its completion or unlocking. You did well to open a ticket manually.
Note for the OVH team (@FabL)
In my view, the migration you are carrying out should implement an automatic fault‑detection and ticket‑creation mechanism. In other words, when the migration process does not finish correctly, the system itself should generate a ticket in your backend, assign it to the appropriate team, and include the full migration trace (operation logs, affected account ID, service status).
This would drastically reduce downtime for the client and prevent a user without access from having to search for alternative channels or wait for a manual ticket to be opened.
From the user’s perspective, this kind of proactivity turns a potentially catastrophic experience into a quickly‑responded, traceable incident, all without the client having to take any steps.
Thanks for your message and I also agree with the note you addressed to OVH: originally such a migration should be invisible to the user, as they promise (because we didn’t request it and it’s mandatory) and so if it doesn’t work, it would be up to them to detect and fix it themselves. In any case I’m waiting for the response on the ticket. So we’ll see…
Bonjour @GeorgesL2 et @fritz2cat (? quel drôle de message, je ne travaille pas pour OVH...),
I finally managed to get it working for two reasons:
First, OVH support finally told me that the webmail was at https://zimbra4.mail.ovh.net/ (and not on zimbra2, which the OVH site redirected to, but saying it wasn’t a mistake, just probably a cache issue on my side )
Then, by trying various combinations of POP servers and authentication types myself, I managed to make it work with the following configuration:
for POP: ssl0.ovh.net as before, port 995, TLS/SSL, password
for IMAP: ssl0.ovh.net, port 993, TLS/SSL, password
Note that now we see it on Zimbra, the mails are in IMAP and not in POP as before (and we weren’t notified about that either)
Summary: one week of mail problems and hours spent testing configurations for an operation we were supposed to “have nothing to do with”, and a support team that does reply but without providing a solution – I was the one who found it.
Have a good day
Note for the OVH team (
)