Hello! Sorry. It's not a short answer.
1) I first transitioned the vB site to AWS so that I had more tools at my disposal. Once I could snapshot servers as backups and knew that I could recover pretty easily, it allowed me the confidence to know that I could forge ahead.
2) I installed Xenforo on a different server. That way I knew if things were working because of how I'd configured the server for Xenforo vs something that was in place for vB. It also allowed me to shut down and snapshot the old vB server when I was done and I don't have remnants of vB on the new server ongoing.
3) I practiced several times so that I knew exactly how long it would take. I'd end up tweaking something every time. The rewrite rules, for instance, that redirect old vB urls to their new Xenforo URL.
4) I had an image that I kept up on AWS of the configuration. Every time I would practice, I'd snapshot that image and start another from that one in order to practice the import. When I finally got everything right I made a snapshot of that image and knew that I could restart the import again from a new clean server if I needed to.
5) We invited a few of our regular users to preview the test install and help us tweak things before we cut over. They were invaluable in finding bugs and other things that would annoy the users. For instance, based on their feedback we completely disabled the Xenforo feature called "profile messages" because they couldn't figure out what they were for. Some profile messages were imported from vB on the initial test runs and I could tell that they'd be confusing...so I just didn't import them and disabled the feature completely.
6) Any time I did the same thing more than 2-3 times, I'd create a script for it. Those scripts are still around and used. One, for instance, sets all of the correct permissions on the Xenforo install after I update the core software.
Code:
<shared some code that I don't want to share publicly>
I wrote this one as the basis for how I update plugins. I have to update paths a little each time, but it leaves a trail for others to follow if they ever had to update things. That was important for me. "Set this thing up so that if I got hit by a bus, there are breadcrumb trails for somebody to follow"
Code:
<shared some code that I don't want to share publicly>
I then added a separate volume for attachments, so that if that ever filled up it wouldn't take the entire server offline. We used ubuntu, so I then turned on "unattended upgrades" so that the server would patch itself. I then implemented SSL. I then put a solid backup solution into place.
Those are what I have for you off the top of my head. Hope that helps!
