I ran into an issue recently while trying to retire a project that shared an org with another project. To give an idea of the scope we are going from nearly 3000 unit tests to just over 400 after the retirement.
The issue is that many of the apex classes that need changing would break other classes that we wanted to destroy post deployment. This did not create an issue in sandboxes but in the production org you can't get away with this, because all existing unit tests need to pass before the deployment is successful.
On the other hand we cannot destroy these classes predeployment, because before deploying the changes to the classes we intended to keep, they rely on code within the classes that we want to destroy.
This creates a catch 22 where there is no point in the deployment process that the destroy won't fail unit tests in PROD. Does anyone know a way around this? I see that workbench may have a way to do a standard deploy and a destructive deploy simultaneously, but I'd prefer to keep them separate if possible.