In a sense refactoring is just moving chunks of code around - sometimes combining chunks, sometimes spliting them. No matter how you cut it, the process you have described is refactoring rather than rewriting. Also in a sense refactoring is all about architecture. When you refactor you are rearchitecting some part of your "design". However, labels don't help you achieve your goal.

Database stuff I don't know much about. However if you take a representative snapshot of your databases that you can work with offline, then you can generate a test framework first against the databases and the code that services them. Then rework the code and databases into the new architecture (developing porting tools as needed along the way), remebering to check against the test framework. If you need to change the live system, make sure anything pertinent is checked by the common test framework and that the reworked system is updated to pass the new tests. Then when the reworked system is deemed ready and passes all tests you can quickly and confidently move the changes back into the live system. So long as both the live system and the reworked system behave as expected against the test framework at the time of the merge every thing should go smoothly.

The two key elements are identifying and implementing interfaces and implementing test frameworks against those interfaces. Once the interfaces are in place you can mix and match client and server code (code on either side of the interface) as you like. To the client code it doesn't matter how the server code does its job and it doesn't matter if it is in the same process, a different process on the same cpu, or a process running on hardware across the other side of the Earth.

Interfaces to provide isolation. Tests to make sure you don't break stuff. It really doesn't matter what you call it.