Automating Hardware Retirement Dates

Managing aging hardware is one of those tasks that sounds simple but becomes complex very quickly at scale. Different assets come from different vendors, have different warranties, and follow different lifecycle rules. Without automation, retirement dates are often missing, inconsistent, or simply wrong. This ServiceNow script addresses that challenge by systematically determining and populating retirement dates for hardware assets using a clear, prioritized logic.

At a high level, the script’s goal is to ensure that every hardware asset has a meaningful retirement date, using the best available data. It does this by working through four logical steps, starting with the most reliable information and falling back to defaults only when necessary.

Follow along with the script at the bottom of the article.

Step 1: Establish a Default Useful Life for Hardware Models

The script begins by standardizing the concept of useful life at the model level. It queries the cmdb_hardware_product_model table and finds any hardware models where the useful_life field is empty. For those models, it sets a default useful life of 36 months.

This step is important because many downstream calculations depend on the model’s useful life. By ensuring that no model is missing this value, the script creates a reliable baseline. While 36 months is used as a default, the structure allows for future customization—such as assigning different lifespans to laptops, servers, or network equipment.

Step 2: Use Warranty Expiration as the Retirement Date

Next, the script moves to the asset level and looks at hardware records in the alm_hardware table. For assets that have a warranty expiration date, it sets the asset’s retirement date to match that warranty end date.

This makes sense from a business perspective. Once a warranty expires, the organization often assumes increased risk and maintenance cost. Using the warranty expiration as the retirement date ensures that assets are flagged for replacement or review at the appropriate time.

Step 3: Fall Back to the Model’s End-of-Life Date

Not all assets have warranty information. For assets that still lack a retirement date but do have an associated model, the script looks to the model’s lifecycle records. It queries the cmdb_hardware_model_lifecycle table to find an active end-of-life phase for the model.

If an end-of-life date exists, that date becomes the asset’s retirement date. This aligns asset management with vendor lifecycle data, ensuring that hardware is not kept in service beyond its supported lifespan.

Step 4: Calculate Retirement Using Created Date + Useful Life

Finally, for assets that still don’t meet any of the previous criteria, the script uses a calculated approach. It takes the asset’s creation date and adds the model’s useful life (in months) to determine a retirement date.

This is the ultimate fallback option, but it ensures that no asset is left without a retirement date. Even when data is incomplete, the system still produces a reasonable and predictable result.

Why This Matters

This script is a great example of defensive, real-world ServiceNow development. It prioritizes the most accurate data sources, gracefully handles missing information, and ensures consistent outcomes across thousands of records. By automating retirement date management, organizations gain better visibility into aging hardware, reduce operational risk, and support more informed refresh planning—all without manual intervention.

In short, this script turns scattered lifecycle data into a dependable, automated asset aging strategy.

updateAgingHardwareDates();
function updateAgingHardwareDates(){
	//1
	//Setting default to 36.
	var grHardwareModel = new GlideRecord('cmdb_hardware_product_model');
	grHardwareModel.addEncodedQuery('useful_lifeISEMPTY');
	grHardwareModel.query();
	while(grHardwareModel.next()){
		grHardwareModel.useful_life = 36;
		grHardwareModel.update();
	}
	
	//2
	//Use the warranty end date for the assets scheduled retirement date on alm_hardware table.
	var grAsset = new GlideRecord('alm_hardware');
	//filter our assets without the warrenty dates.
	grAsset.addEncodedQuery('warranty_expirationISNOTEMPTY');
	grAsset.query();
	while(grAsset.next()){
		grAsset.retirement_date = grAsset.warranty_expiration;
		grAsset.update();
	}

	//3
	//For assets that still have an empty scheduled retirement, find the associated models end of life date if there is one.
	var grAsset2 = new GlideRecord('alm_hardware');
	//filter our assets with pre defined scheduled retirement dates and assets with no models.
	grAsset2.addEncodedQuery('retirement_dateISEMPTY^modelISNOTEMPTY');
	grAsset2.query();
	while(grAsset2.next()){
		//Find the related model cmdb_hardware_model_lifecycle end of life record.
		var grHardwareLifeCycle = new GlideRecord('cmdb_hardware_model_lifecycle');
		//filter out inactive records and records with no date.
		grHardwareLifeCycle.addEncodedQuery('model=' + grAsset2.model + '^active=true^lifecycle_phase=end_of_life^start_dateISNOTEMPTY');
		grHardwareLifeCycle.query();
		if(grHardwareLifeCycle.next()){
			grAsset2.retirement_date = grHardwareLifeCycle.start_date;
			grAsset2.update();
		} else {
			//4
			//Pull the useful life from the model and rely on the default computation. Which is the "created" date of asset plus the useful life of the associated model.
			var grHardwareModel2 = new GlideRecord('cmdb_hardware_product_model');
			if(grHardwareModel2.get(grAsset2.model)){
				var gdt = new GlideDateTime(grAsset2.sys_created_on);
				gdt.addMonthsLocalTime(grHardwareModel2.useful_life);
				grAsset2.retirement_date = gdt;
				grAsset2.update();
			}
		}
	}
}

Conclusion

Automating hardware retirement dates in ServiceNow ensures every asset has a consistent, defensible lifecycle plan. By leveraging warranty data, model lifecycle records, and useful life logic, you create cleaner data and more reliable refresh planning.

Want to implement this in your environment? Contact us to get started.