---
schema_version: "1"
id: 96a7208ad16953dae695b1e35a838ff8133a75a0d1b226a9c33291b21d6ecc8f
title: Slow Deployments
collection: legacydeveloper
version: current
locale: en-us
portal_url: https://docs.salesforce.com/legacydeveloper/current/en-us/api_meta/meta_deployment_service_upgrade.md
canonical_url: https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_deployment_service_upgrade.htm
source_site: developer.salesforce.com
content_type: documentation
content_hash: ba108576f22a6230b05ea2822a447dcfd2833b0ea7ad1e78acdab8ab67aebdd0
description: If a file-based Metadata API deployment occurs during server downtime, such as a Salesforce service upgrade, the deployment can take longer than expected. This behavior happens because both component deployment and validation are retried from the beginning after the service is restored. However, if Apex tests were part of the deployment, only tests that weren’t run before the downtime are run.
---
# Slow Deployments

If a file-based Metadata API deployment occurs during server downtime, such as a Salesforce service upgrade, the deployment can take longer than expected. This behavior happens because both component deployment and validation are retried from the beginning after the service is restored. However, if Apex tests were part of the deployment, only tests that weren’t run before the downtime are run.

This behavior affects file-based deployment and retrieval, change sets, some package installs and upgrades, second-generation managed package creation, and deploys and retrieves started from the Salesforce CLI or the Salesforce VS Code extensions. It doesn’t affect CRUD-based metadata operations.

If your instance is due for a planned service upgrade, avoid running deployments during the service upgrade. To check whether your Salesforce instance is due for an upgrade, check Salesforce Trust. Salesforce performs major service upgrades three times per year and other maintenance updates throughout the year.