No idea what kind of stuff you're usually up to, and where I worked we ran customised versions of our software for clients so it was just 'old-fashioned' SaaS rather than Cloud-based, so sorry if this comes in as too obvious or something...
Maybe its just me, but what I'd suggest is that you focus on what you need it to do rather than start going on about cloud or whatever method of putting it together if you've not spoken to the IT team yet; depending on how your IT Department feel, it may turn out that they'd rather do the workings of it differently.
Every time I've seen clients get too focussed on the how instead of what and why, its wasted loads of time.
Essentially, sounds like you've got a reasonable grip on the requirements to start with, which is the main thing.
You need to know as accurately as possible what you're going to actually be using the site for & how it fits into the regular work you do. Once you've got that figured out, the next thing will be sitting down with the IT guys & figuring out what you actually need from the site, as some things may not map directly across from what you have now - I've seen weeks wasted because the client wanted a button that did X, just like their old system. While the equivalent button on ours did X,Y and Z - they were so insistent nobody sat down and said "look, do you need the intermediate steps for some reason?" until it came to us making it and we said "did nobody suggest they use the button we've already got? Its better and its already there..." and the project manager and the analyst suddenly went quiet... They then pointed out the standard setup, and the customer thought it was the best thing since sliced bread.
Don't worry about look and feel too much until you actually have the requirements sorted out, as obviously its dependent on that.
As you're doing it in stages make sure its very clear what each stage contains & what stuff is interlinked - also make sure you're prepared for what happens if certain features aren't going to be ready for a particular stage - does it mean that if you don't have X ready on time, you delay the release until its ready or do you push the feature back to the next stage?
If the IT guys suggest something that comes across as a silly suggestion, make sure you ask why they've suggested it, don't just go "no" - ask why they suggested it. It may turn out they're asking it for a reason other than just not getting it (for example, to avoid running into a limitation of some framework they're planning on using, or something like that), so asking can avoid a whole lot of trouble.
Learn how the IT guy you're dealing with does his estimates when you're figuring out the deadlines. This is probably a bit better than I'm used to as its an internal team rather than using an external company where you can end up with a project manager who's happy to promise things to happen immediately and take a day that the technical team will look at and go "no. That'll take a week and we can't start till Tuesday because X needs to be done first" . Most people will figure out a rough timeframe and add a little extra just in case things go wrong, though this varies a lot based on how optimistic the people you're dealing with are (my old boss had a really bad habit of giving best and worst case then promising the best-case, so it looked like stuff was late 75% of the time instead of early 25% / on target 75%). In which case, be aware of the best and the worst case, and assume that if it can go wrong it will so don't get suprised when someone says "it'll be sometime this week, probably wednesday to friday" and it turns up Friday afternoon not Wednesday.
Leave plenty of overrun time in the schedule and don't try and squeeze in "one more thing" if it looks like you're on-time unless you know for sure its a very minor thing because sods law says that one thing will always be a nightmare; use the time for extra testing instead.
Also, don't push for stuff to be delivered if you don't even know what it is you need delivered yet. Sounds crazy, but you hear a lot "oh we need it by tuesday"... "what do you need exactly?" ... "dunno..." - figure it out, then do it. Saves wasting time, actually gets you it faster.
When you're testing out prototypes and such, if someone goes "we need to bring it down to make some changes", try and be flexible, and allow for overruns. If they say it needs to go down for say 3 hours don't push hard on the limits of that. I've had situations where project managers have gone "oh, they need that test system - we can only have it down for 2 hours", when it takes 6 hours to run the upgrade script...
Sorry if that's pretty general stuff - I've not actually been on the analysis side, but while I've been speaking to customers to clear up some complete messes of specs for customisations, builds, upgrades etc. I've been given, that's the kind of repeat problems I used to see.