A challenging task. I haven't done this myself, though I have experience with OpenStack HA setup "by design". Let's break it down by service type and network components, assuming you're familiar with the OpenStack HA guide and have an idea how to configure the individual services:

• Database - Bootstrapping Galera cluster from a standalone node is a relatively uncomplicated task with just a short downtime needed. You place in the config, stop the service, start it with service mysql bootstrap (assuming systemd on Ubuntu 16.04) or a more versatile variant service mysql start --wsrep-new-cluster. Then you start the other nodes, wait for SST (initial data transfer) and then restart the first node, just so that it runs in "normal" mode and not in "bootstrap" mode, vaguely said. Have a look at this writeup, for example. WARNING: As always, do a backup before taking any action. Bootstrapping against an empty node by mistake WILL wipe out your database.
• Message queue - This one also requires some downtime, but you face almost no danger since OpenStack doesn't keep any long-lived persistent data in there. Just configure RabbitMQ according to the HA guide and make a cluster out of the conrollers' instances.
• Corosync - Virtual IP - This Virtual IP will be a new element in your cluster, so no breaking change here. Again, HA Guide has you covered. It's basically an IP address that's always up and present on the controller that's working.
• HAProxy and all the "listening" services with it - Although it is possible to just run on the Virtual IP, I strongly recommend putting a traffic balancer in between the Virtual IP and other services. The HA Guide's HAProxy config is a very good start, but you'll have to configure all the services that listen on all interfaces by default to just listen on the controller's management IP address. This is because HAProxy will be listening on the Virtual IP address, which would be impossible if the port would already have been taken. You'll need to search through each project's config refrence; look for the keywords "bind" or "listen" in general (e.g. for Nova, it's osapi_compute_listen and metadata_listen for its two APIs)

And then there's Neutron. Basically this is a change that is independent of your effort to make management highly available, so I advise you not to do this in the same run, just to concentrate on one thing and to do it well.

The same goes for the OpenStack upgrade by the way - my personal approach would be: upgrade first, then do the management HA setup, then fiddle with Neutron.

In general, introducing a new network scenario to Neutron doesn't work without downtime (planned or not, sadly). I advise you to go through:

• OpenStack networking to get familiar with the concepts and terminology
• OpenVSwitch deployment scenarios to identify which scenario you have set up at the moment and which one you'd like to have ...