How should you handle the situation ?
You have identified potential for improvement. But patterns are just means to design software better and faster. So when the software is already designed and implemented, there is no obligation to adopt the latest patterns.
If your system has a modular design, and allows for new components to be developed without significant dependency to existing constructs, just do as your boss said :-)
How does your boss think ?
- "Never change a running system" : Change of patterns would require extensive redesign, which might quickly propagate through dependencies and end-up in a complete overhaul of the system
- If such change is required, how to handle the risk of instability during the reimplementation ?
- How can the new version be tested ? If TDD was used, just reuse all the test cases and the risk is managed. But if not, are all the tests proving the reliability still known ?
- What benefit would the change of patterns bring to the customer ?
- What's the cost of reimplementing, and what economic benefits (cost saving, revenue) could it bring ? And how does this picture compare to cost incurred by keeping the existing patterns ?
- Is someone ready to pay for the change ?
How do the user think ?
- I've plenty of work to do, and the system should help me
- A major redesign was undertaken, but nothing changes for my daily work, except that there could be a lot of new bugs to handle.
- I have no time to invest on a huge acceptance test, just for obscur technical matters.
I don't have the answers to all these questions. Your boss has certainly done this kind of analysis. That's what bosses are paid to do. So work as he told you :-) ...
...unless you think that the old patterns have major drawbacks that are not fully understood by your boss. For example if the old patterns make the system difficult to operate and maintain ("technical debt"). In this case you should go back to your boss and make sure he understand the hidden costs of the legacy in his cost/benefit analysis.