If you have worked with a system of any significant age I am certain you have heard the term technical debt. It is what you owe the system from your accumulated shortcuts and hacks. And any further effort not focused on repaying this debt will lead to increased interest.
Your technical debt directly affects the velocity of your team. As the code becomes stale, your new additions and maintenance becomes slower and slower. This is what Steve McConnel calls paying service, where a large enough debt can grow to require more spending on its service than investing in increasing the value.
What else is that technical debt affects the morale of your team. A perceived low quality makes it easier to slip by more bad code and thus you are in a downward spiral with rotting software.
So you must start settling your technical debt.
Approaching your debt
One important question to ask is, if you were starting from scratch today what would you do differently? Realizing what your dream scenario would look like is a good first step. This ideal setup is probably what would give your team the highest velocity possible.
The next question you should ask yourself is for how long you will maintain this project. If it just a few weeks then you might afford being short sighted and just pick the low hanging fruits. But if you are looking at several months, or years ahead then perhaps you should look at making a heavier investment and go for something closer to the best setup possible.
What matters in the end is the results - how much value you are cranking out. This can come from either a long development time with low velocity or a shorter development time with higher velocity coming from an up-front investment of educating the team, refactoring code, learning new technology, etc.
What is better suited for your particular case is very much depending on your unique conditions. Any down payment on your debt is better than nothing but as always there is merit in taking a step back and looking at the big picture.