I also have been working in similar situations and I can give you the following advice.

1. You need to reduce technical debt. Now. Why? Because technical debt is like financial debt. You will pay interest on it.
2. Since refactoring the whole code base is not feasible, ask yourself: what is preventing it? Is it simply too much work? Why?
3. Create a plan to reduce technical debt in time. For example, by setting up rules as "every bit of code that is touched by the team must be fixed/refactored to the new standard". Typically: unit tests must be written, code must be moved in the correct layers, etc. This allows you to fix a lot of code without resorting to ridiculously expensive and low value "refactoring" projects.
4. Wrap the crap. Decoupling is key to refactoring and good architecture. If you can partition the code base somehow, you can maybe refactor smaller bits.
5. Do not increase tech debt further. Do not increase tech debt further. Do not increase tech debt further. Do not...

I also have been working in similar situations and I can give you the following advice.

1. You need to reduce technical debt. Now. Why? Because technical debt is like financial debt. You will pay interest on it.
2. Since refactoring the whole code base is not feasible, ask yourself: what is preventing it? Is it simply too much work? Why?
3. Create a plan to reduce technical debt in time. For example, by setting up rules as "every bit of code that is touched by the team must be fixed/refactored to the new standard". Typically: unit tests must be written, code must be moved in the correct layers, etc. This allows you to fix a lot of code without resorting to ridiculously expensive and low value "refactoring" projects.
4. Wrap the crap. Decoupling is key to refactoring and good architecture. If you can partition the code base somehow, you can maybe refactor smaller bits.
5. Do not increase tech debt further. Do not increase tech debt further. Do not increase tech debt further. Do not...

I also have been working in similar situations and I can give you the following advice.

1. You need to reduce technical debt. Now. Why? Because technical debt is like debt. You will pay interest on it.
2. Since refactoring the whole code base is not feasible, ask yourself: what is preventing it? Is it simply too much work? Why?
3. Create a plan to reduce technical debt in time. For example, by setting up rules as "every bit of code that is touched by the team must be fixed/refactored to the new standard". Typically: unit tests must be written, code must be moved in the correct layers, etc. This allows you to fix a lot of code without resorting to ridiculously expensive and low value "refactoring" projects.
4. Wrap the crap. Decoupling is key to refactoring and good architecture. If you can partition the code base somehow, you can maybe refactor smaller bits.
5. Do not increase tech debt further. Do not increase tech debt further. Do not increase tech debt further. Do not...

I also have been working in similar situations and I can give you the following advice.

1. You need to reduce technical debt. Now. Why? Because technical debt is like financial debt. You will pay interest on it.
2. Since refactoring the whole code base is not feasible, ask yourself: what is preventing it? Is it simply too much work? Why?
3. Create a plan to reduce technical debt in time. For example, by setting up rules as "every bit of code that is touched by the team must be fixed/refactored to the new standard". Typically: unit tests must be written, code must be moved in the correct layers, etc. This allows you to fix a lot of code without resorting to ridiculously expensive and low value "refactoring" projects.
4. Wrap the crap. Decoupling is key to refactoring and good architecture. If you can partition the code base somehow, you can maybe refactor smaller bits.
5. Do not increase tech debt further. Do not increase tech debt further. Do not increase tech debt further. Do not...