If you’re trying to reduce risk, do the hard part first. That way, if it fails, you’ll have minimized your time and effort.
On the other hand, if you’re looking for buy-in and commitment so you can get through the hard part, do it last. People are terrible at ignoring sunk costs, and the early wins and identity shifts that come from the easy successes at the beginning will give you momentum as you go.
The hardest part of scaling a system is getting pieces of the current system to work with the new scaled out versions. Design and implementation are usually much more work, and take much more time.
Design and implementation don't involve working with the imperfections of past design and implementation. They don't have political agendas, and they aren't too busy to make the changes you need.
From my experience, the hardest part of any project built in isolation, is bringing the system from isolation to production. Whether you are bringing in a scaling framework, doing a rewrite, or building a new product; you and your team can write the software. You can shape it how you want or need because it is in isolation. Getting out of isolation requires changing your software to match production, and changing production is very hard.
Save yourself and your team, get your software into production from the beginning. Otherwise you may find yourself throwing away a year's worth of work because getting into production is the hard part.