Skip to main content

How to delete a class from production using Ant Migration Tool on Windows | JET BI

About Us
Published by jetbi
25 March 2022
170

Let’s imagine a situation when some Apex classes are no longer used in production. In that case, Salesforce recommends removing those classes from production to keep it clean from anything unnecessary. We can do that in a number of ways but that guide is dedicated to the Ant Migration Tool. The Ant Migration Tool is a Java/Ant-based command-line utility for moving metadata between a local directory and a Salesforce Org. For more information on tool usage cases visit the site. This article is aimed to acquaint you with the basics of the Ant Migration Tool and build your first solution to delete custom Apex Class from Salesforce Org.

 

1 Preliminary

Before you install the Ant Migration Tool you need Java and Ant to be set up on your local machine. Then you can download the Ant Migration Tool from a Salesforce Org. The detailed guide is under the link.

2 Delete Apex Class from an Org

2.1 Create project

Enter the folder where the Ant Migration Tool was installed. You can see the ant-salesforce.jar file, a brief description in the Readme.html file, and the sample folder with build.properties and build.xml files. We will use those files as templates in our project but firstly we should create our own project. In the directory with ant-salesforce.jar create a new folder named ‘removeClass’ as per image: 

1-ant-tool

 

You can switch to another directory, but you shouldn’t forget to change the path for ant-salesforce.jar in the build.xml file.

2.2 Enter connection information

In order to connect to the Salesforce Org, you should provide either username with password, active Salesforce session, or OAuth access token. For more information visit this site. In that guide, we will use a username and password. Copy the build.properties file from the sample folder to your project’s folder. Then open with a text editor, and populate sf.username and sf.password parameters with your credentials. Make sure to add a security token to your password, cause you are accessing Salesforce via the desktop client. If you don’t know how to reset your security token visit this link for clarification. Populate sf.serverurl parameter and comment other parameters. Save the file. It should look like this:

2-ant-tool

 

2.3 Create package.xml

In general, to delete components the same procedure as with deploying components must be used, but also include manifest file removing that’s named destructiveChanges.xml and list the components to delete in this manifest. The format of this manifest is the same as package.xml. And to deploy the destructive changes, you must also have a package.xml file that lists no components to deploy, includes the API version, and is in the same directory as destructiveChanges.xml. Let’s create our own. Move to your project’s folder location. Inside the removeClass folder create a new folder called codepkg where the manifest files will reside. Inside codepkg create destructiveChanges.xml file and populate it with the class definition you want to delete. It should look like this:

3-ant-tool

 

Then create an empty package.xml next to destructiveChanges.xml:

4-ant-tool

 

2.4 Create undeploy target

The build.xml file specifies a series of commands to be executed by Ant Migration Tool. Within the build.xml file are named targets that process a series of commands when you run Ant with a target name. This is the place where we create our own target to remove the class from Salesforce Org. Copy build.xml file from sample folder and paste into removeClass folder. Open this file in the text editor. Remove all targets except one with the name undeployCode. It will be our end target. Make sure you have a path to ant-salesforce.jar specified, deployRoot parameter is set to codepkg and target name is undeployCode:

5-ant-tool

 

Also make sure the rollbackOnError parameter of the deploy command is set to true or omitted, as it defaults to true. For looking to other parameters you may specify in deploy command 

2.5 Execute

Open your command prompt (WIN + ‘R’) and navigate to the removeClass folder. Then run the command ant undeployCode. Expected result - BUILD SUCCESSFUL:

5-ant-tool

 

3 Conclusion

Ant Migration Tool is a powerful tool to manipulate metadata on Salesforce Org. Specific Apex class was deleted successfully from Production Org. If you faced any issue during performing this task, check this helpful article with resolutions and best practices.

 


Dmitriy Gatsenko
image
image

We have available resources to start working on your project within 5 business days

1 UX Designer

image

1 Admin

image

2 QA engineers

image

1 Consultant

image
Related Articles
All articles
image
Is Salesforce Winning the Public Sector Race?
An analysis of Salesforce's rapid expansion into the U.S. public sector, tracing its path from cautious early government licensing deals in the 2010s through the launch of Government Cloud in 2012, its pivotal role in COVID-19 vaccine rollouts, and its 2025–2026 push into military and intelligence work via Agentforce and Missionforce. The piece covers major 2026 contracts — including a $5.6 billion Army deal, a $1.6 billion VA agreement, and Pentagon Impact Level 5 authorization — alongside real-world case studies like California's REAL ID processing and the UK's NHS back-office operations. It also examines the structural obstacles still facing Salesforce and other vendors in government tech: legacy IT systems decades old, outdated federal procurement rules, budget constraints, and organizational caution around AI adoption, plus the competitive pressure from Palantir, Microsoft, and Oracle in the race for public sector AI spending.
28 August 2026
image
Why Your Salesforce Flows Are Agentforce's Biggest Problem
This article argues that the most underestimated risk in Agentforce deployments isn't data quality — it's the automation layer: years of overlapping Flows, Process Builder processes, Apex triggers, and managed package logic that no one has reviewed end-to-end. It explains why AI agents inherit automation complexity without the tribal knowledge human admins carry, why technical debt only becomes visible after an agent hits it in production, and why a clean demo is no indicator of production readiness. The article closes with a concrete, tool-by-tool inventory approach using Flow Trigger Explorer, Salesforce Optimizer, Setup Audit Trail, Apex Debug Logs, Agent Builder, and Health Check — scoped to the specific processes the agent will actually use rather than the whole org.
23 July 2026
image
How to Wire Multiple Salesforce Projects in One Org Without Breaking Everything
This article maps the real integration patterns that emerge when multiple Salesforce projects — both managed packages and unpackaged code — share a single org. It covers four concrete patterns: attaching custom triggers to package-owned objects, calling global members exposed by managed packages, writing directly into another project's objects, and runtime-guarded reads of package data. It then addresses access control for authenticated and guest users, including the Master-Detail wall and the without sharing elevation pattern. The piece closes with eight concrete risks (compile-time dependencies that block uninstall, upgrade coupling, silent cascade failures, access invisible to admins) and six actionable recommendations for keeping cross-project coupling manageable.
08 July 2026