How do I destroy apex classes in production if there are dependencies in both the pre and post deployment state?

Question

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.

Answer 1

In the end this is the answer we came up with.

We broke our deployment into two stages:

STAGE 1: Code changes include any updates to code we are keeping, as well as gutting any classes we intend to remove, leaving nothing but the signature. This made it so only the code and unit tests we were keeping ran as part of PROD deployment. After this deployed successfully we THEN ran the destructive deployment to remove all the deprecated classes.

STAGE 2: Deploy a change that simply deletes all the empty, deprecated classes

This was simple to implement and worked with almost no issues. Two points of caution though.

1. If you are gutting triggers, keep in mind that you will still need at least one dummy test associated with each trigger or you will fail code coverage in the stage 1 deployment
2. Be aware that if you have classes in production but not in your source code, and those classes are to be deprecated, you will want to add empty versions to your source for stage 1 deployment.