In summary, the challenge is, what would you deliver after four months, where the problem is what is sketched in the image on the right.
Let's start to discuss the easiest two items: new branding and old technology. Then we must think about the remaining things: new user experience and transactions. Finally I will list what I think about deliverables.
First, the only thing that seems directly related to the deadline of four months is the branding. As it needs to be flipped in production instantaneously, I would want a switch in the configuration somewhere. That way, the new brand can be tried and tested easily before switching for real. Such a switch would allow an incremental change of the various pages of the site.
W3c compliance does not sound like a real requirement. As a bank, I would want all major browsers to work with my site. If standards help, cool; if not, who cares. But the requirement comes from somewhere: it may indicate that there has not been enough testing for portability in the past. While going over all pages for the new branding, this can be improved at the same time: the Definition of Done for a page switched to the new brand should include portability to the supported browsers.
This effort seems to stand on itself. It might be done independently from the rest. But it could be that the old system "no longer being fit" and the new system "providing a better user experience" will interfere.
As a matter of course we need to figure out how hard this deadline is, or whether it might be changed to 3 months.
Technology no longer supported by vendor
What? Who was sleeping? Now we have to do some firefighting!
Have there been problems with the technology, ever? If not, there is no reason to worry/hurry.
Is there an obvious path for upgrading? If so, do so.
Is the technology open source (or can it be open sourced)? Form a team to do so, or find an external partner (not the vendor, probably) that is willing to take support.
A last resort, prepare to replace the technology with a competing solution (preferably vendor agnostic).
If the technology is core to our banking business, it is more important to keep it in-house.
This effort must stand on itself. If the vendor pulls the plug before replacement can be finished, we have a serious problem and should warn the customer immediately.
No transactions on a read-only copy
First, the read-only copy should be the same thing as the real data. If that is not the case, make it so.
The second step depends largely on experience of the teams: transactions are to prevent inconsistent data (both [writing to] the DB and [reading into] memory). Some reading sequences must become transactions. Most writing sequences will be transactions, and will enforce more reading sequences to become transactions. If the team understands this, and can handle this, growing features and switching to transactional access can be done at the same time. That provides new functionality in increments.
If the teams lack experience, it might be better to enforce all reading sequences to be transactions, and only then add write transactions and/or new features.
Either way, in my experience, this is risky business. So independent of the road taken, the teams must come up with (testing) strategies that will demonstrate that the transactions are working as intended. We should hire experts to help them if they can not do this themselves.
As with the new branding, the new system "providing a better user experience" may interfere. In fact, that appears likely to me.
What to deliver?
There are likely two or more powerful stakeholders driving the new user experience and the new branding. We need to figure out which one is the most powerful, and put priority there. Also, risk drives priority: when the vendor pulls the plug, and how definitive that is, determines a lot. The new user experience might raise the risk of the other two jobs a lot.
The new branding should be delivered incrementally and iteratively: something to show every two weeks; a month for the first increment perhaps; on a weekly basis or even faster close to the deadline.
The rest is much less clear without additional information.
The technology replacement should go in a separate branch to be merged when done, if possible. Whether the merge can be done before or after the 4 months deadline, I can not tell you now.
The new user experience should be incremental and iterative, like the new branding. But in parallel or afterward, I can not tell you now.
The new user experience could drive the switch to live data in a transactional way, but I need a lot more information before I would commit to that. Perhaps the refactoring to a transactional way must be done before adding any new user experience. In that case, whether it is done in parallel with the rebranding or afterward; once more, I can not tell you now.