Tech Advisory

Technology Advice for Small Businesses

powered by Pronto Marketing

Recent Posts

Why VoIP call transfers fail between phone systems

Editor November 11, 2026

A call transfer may seem simple, but behind the scenes, multiple phone systems must coordinate how to pass an active call to another person or number. They do this through SIP messages, which different vendors may handle in their own ways. When systems don’t agree, calls can drop, callers may hear silence, or transfers may fail when dialing an outside number. Understanding how the process works makes these issues easier to troubleshoot.

How a SIP transfer works

A SIP call transfer involves three parties: the transferor, who initiates the transfer; the transferee, whose call is being moved; and the target, who receives the call.

Most transfers use the SIP REFER method, defined in RFC 3515 (The Session Initiation Protocol REFER Method). This RFC defines how one SIP device can ask another to make a new request, such as starting a call to a different destination. The destination is included in the Refer-To header, while the Referred-By header identifies who requested the transfer.

The receiving system then sends a new INVITE, the SIP method used to initiate a call, to the target. It reports the call’s progress through NOTIFY messages, which communicate updates such as whether the new call is ringing or has connected.

The process depends on the type of transfer. A blind transfer sends the call to the target immediately, without first checking their availability. An attended transfer allows the transferor to call the target first and confirm they are available before completing the handoff. It uses the Replaces header, defined in RFC 3891 (The SIP Replaces Header), to identify the existing call that the new call should take over.

For a broader look at how these mechanisms work together, RFC 5589 (Session Initiation Protocol Call Control – Transfer) describes recommended practices and call flows for implementing SIP transfers, including blind and attended transfers.

Where interoperability breaks down

SIP transfer failures usually fall into a few common categories. The first is support mismatch: not every phone system or carrier supports REFER. Microsoft Teams Direct Routing documentation provides an example of how platforms handle this, listing a fallback order of REFER, INVITE with Replaces, and then an internal transfer method that the session border controller (SBC), which manages SIP traffic between networks, cannot see. These fallback methods can behave differently, sometimes leaving callers unable to hear the phone ringing while waiting for an answer.

Header handling is another common issue. A REFER request may not contain all the information needed to route the new call, so Microsoft expects the SBC to preserve the Refer-To and Referred-By headers when creating the new INVITE. That INVITE must go back to the platform’s SIP proxy rather than directly to the telephone network. Rewriting the headers or routing the INVITE elsewhere can break the transfer.

Missing progress messages can also cause failures. The receiving system should respond to REFER with “202 Accepted” and send NOTIFY messages to report progress. If these messages never reach the initiating system, it may time out. If a BYE message, which ends an established call, arrives too early, the original call can drop before the transfer completes.

Firewall rules add another potential obstacle. REFER requests may arrive over new TLS connections from any of the platform’s signaling addresses. Firewalls that allow only specific addresses can block these requests, even when other SIP traffic works normally.

Finally, carrier behavior and platform updates can introduce unexpected problems. A 481 Call/Transaction Does Not Exist response means the receiving system can no longer find the referenced call or transaction. During an attended transfer, this can happen when the transferor’s temporary call to the intended recipient (known as a consultation call) stays on hold long enough for a carrier device to expire it.

Platform changes matter too. In June 2026, Microsoft changed its blind-transfer behavior so its side ends the original call as soon as the SBC accepts the transfer, without waiting for the final result. Configurations that worked under the previous behavior may therefore need to be reviewed.

Practical troubleshooting checks

Start by identifying the transfer type (blind or attended), its direction, and which system receives the REFER request. Capture SIP traces of both a failed and successful transfer using SBC logs or a packet capture, then compare the messages to find where they differ.

Check whether REFER is listed in the Allow header on each leg of the call. If a system does not support REFER, removing it from the advertised methods may force some platforms to use INVITE with Replaces as a temporary workaround.

Next, verify that the new INVITE preserves the Refer-To and Referred-By values and that 202 Accepted and NOTIFY messages reach the system that initiated the transfer. Check message timing too, particularly whether a BYE arrives before the final NOTIFY. If callers hear silence instead of ringing, check REFER support and the handling of 180 Ringing and 183 Session Progress responses, which provide call-progress updates.

Also review firewall rules to ensure all required signaling addresses are allowed, and confirm that destination numbers use the format expected by the next system.
Finally, test internal and external transfers separately, including both blind and attended transfers across desk phones, softphones, and mobile devices. Comparing the results helps identify which system or network connection is causing the failure.

Call transfer failures between your phone system, carrier, or cloud platform can be difficult to diagnose. Our team can capture and analyze SIP traffic, identify where the handoff breaks, and help get your calls transferring reliably. Contact us to start troubleshooting.

Blind, attended, and broken: What happens when phone systems hand off a call

Editor November 11, 2026

Call transfer issues can be difficult to diagnose because users rarely report a rejected SIP REFER. Instead, they simply say the call dropped when they tried to transfer it to a colleague. Behind the scenes, the transfer involves several systems that must coordinate the handoff. When something goes wrong, understanding how these systems interact makes it easier to identify where the transfer failed and why.

How a SIP transfer works

A SIP call transfer involves three parties: the transferor, who initiates the transfer; the transferee, whose call is being moved; and the target, who receives the call.

Most transfers use the SIP REFER method, defined in RFC 3515 (The Session Initiation Protocol REFER Method). This RFC defines how one SIP device can ask another to make a new request, such as starting a call to a different destination. The destination is included in the Refer-To header, while the Referred-By header identifies who requested the transfer.

The receiving system then sends a new INVITE, the SIP method used to initiate a call, to the target. It reports the call’s progress through NOTIFY messages, which communicate updates such as whether the new call is ringing or has connected.

The process depends on the type of transfer. A blind transfer sends the call to the target immediately, without first checking their availability. An attended transfer allows the transferor to call the target first and confirm they are available before completing the handoff. It uses the Replaces header, defined in RFC 3891 (The SIP Replaces Header), to identify the existing call that the new call should take over.

For a broader look at how these mechanisms work together, RFC 5589 (Session Initiation Protocol Call Control – Transfer) describes recommended practices and call flows for implementing SIP transfers, including blind and attended transfers.

Where interoperability breaks down

SIP transfer failures usually fall into a few common categories. The first is support mismatch: not every phone system or carrier supports REFER. Microsoft Teams Direct Routing documentation provides an example of how platforms handle this, listing a fallback order of REFER, INVITE with Replaces, and then an internal transfer method that the session border controller (SBC), which manages SIP traffic between networks, cannot see. These fallback methods can behave differently, sometimes leaving callers unable to hear the phone ringing while waiting for an answer.

Header handling is another common issue. A REFER request may not contain all the information needed to route the new call, so Microsoft expects the SBC to preserve the Refer-To and Referred-By headers when creating the new INVITE. That INVITE must go back to the platform’s SIP proxy rather than directly to the telephone network. Rewriting the headers or routing the INVITE elsewhere can break the transfer.

Missing progress messages can also cause failures. The receiving system should respond to REFER with “202 Accepted” and send NOTIFY messages to report progress. If these messages never reach the initiating system, it may time out. If a BYE message, which ends an established call, arrives too early, the original call can drop before the transfer completes.

Firewall rules add another potential obstacle. REFER requests may arrive over new TLS connections from any of the platform’s signaling addresses. Firewalls that allow only specific addresses can block these requests, even when other SIP traffic works normally.

Finally, carrier behavior and platform updates can introduce unexpected problems. A 481 Call/Transaction Does Not Exist response means the receiving system can no longer find the referenced call or transaction. During an attended transfer, this can happen when the transferor’s temporary call to the intended recipient (known as a consultation call) stays on hold long enough for a carrier device to expire it.

Platform changes matter too. In June 2026, Microsoft changed its blind-transfer behavior so its side ends the original call as soon as the SBC accepts the transfer, without waiting for the final result. Configurations that worked under the previous behavior may therefore need to be reviewed.

Practical troubleshooting checks

Start by identifying the transfer type (blind or attended), its direction, and which system receives the REFER request. Capture SIP traces of both a failed and successful transfer using SBC logs or a packet capture, then compare the messages to find where they differ.

Check whether REFER is listed in the Allow header on each leg of the call. If a system does not support REFER, removing it from the advertised methods may force some platforms to use INVITE with Replaces as a temporary workaround.

Next, verify that the new INVITE preserves the Refer-To and Referred-By values and that 202 Accepted and NOTIFY messages reach the system that initiated the transfer. Check message timing too, particularly whether a BYE arrives before the final NOTIFY. If callers hear silence instead of ringing, check REFER support and the handling of 180 Ringing and 183 Session Progress responses, which provide call-progress updates.

Also review firewall rules to ensure all required signaling addresses are allowed, and confirm that destination numbers use the format expected by the next system.
Finally, test internal and external transfers separately, including both blind and attended transfers across desk phones, softphones, and mobile devices. Comparing the results helps identify which system or network connection is causing the failure.

Call transfer failures between your phone system, carrier, or cloud platform can be difficult to diagnose. Our team can capture and analyze SIP traffic, identify where the handoff breaks, and help get your calls transferring reliably. Contact us to start troubleshooting.

When a transferred call drops: How to troubleshoot SIP interoperability issues

Editor November 11, 2026

Transfer failures between phone systems usually come down to a handful of common issues. One system may not support the transfer method, SIP headers may get changed along the way, progress messages may not come through, or a firewall may block the signaling. Each issue leaves clues in the SIP logs, making it easier to identify what’s going wrong and find the right fix.

How a SIP transfer works

A SIP call transfer involves three parties: the transferor, who initiates the transfer; the transferee, whose call is being moved; and the target, who receives the call.

Most transfers use the SIP REFER method, defined in RFC 3515 (The Session Initiation Protocol REFER Method). This RFC defines how one SIP device can ask another to make a new request, such as starting a call to a different destination. The destination is included in the Refer-To header, while the Referred-By header identifies who requested the transfer.

The receiving system then sends a new INVITE, the SIP method used to initiate a call, to the target. It reports the call’s progress through NOTIFY messages, which communicate updates such as whether the new call is ringing or has connected.

The process depends on the type of transfer. A blind transfer sends the call to the target immediately, without first checking their availability. An attended transfer allows the transferor to call the target first and confirm they are available before completing the handoff. It uses the Replaces header, defined in RFC 3891 (The SIP Replaces Header), to identify the existing call that the new call should take over.

For a broader look at how these mechanisms work together, RFC 5589 (Session Initiation Protocol Call Control – Transfer) describes recommended practices and call flows for implementing SIP transfers, including blind and attended transfers.

Where interoperability breaks down

SIP transfer failures usually fall into a few common categories. The first is support mismatch: not every phone system or carrier supports REFER. Microsoft Teams Direct Routing documentation provides an example of how platforms handle this, listing a fallback order of REFER, INVITE with Replaces, and then an internal transfer method that the session border controller (SBC), which manages SIP traffic between networks, cannot see. These fallback methods can behave differently, sometimes leaving callers unable to hear the phone ringing while waiting for an answer.

Header handling is another common issue. A REFER request may not contain all the information needed to route the new call, so Microsoft expects the SBC to preserve the Refer-To and Referred-By headers when creating the new INVITE. That INVITE must go back to the platform’s SIP proxy rather than directly to the telephone network. Rewriting the headers or routing the INVITE elsewhere can break the transfer.

Missing progress messages can also cause failures. The receiving system should respond to REFER with “202 Accepted” and send NOTIFY messages to report progress. If these messages never reach the initiating system, it may time out. If a BYE message, which ends an established call, arrives too early, the original call can drop before the transfer completes.

Firewall rules add another potential obstacle. REFER requests may arrive over new TLS connections from any of the platform’s signaling addresses. Firewalls that allow only specific addresses can block these requests, even when other SIP traffic works normally.

Finally, carrier behavior and platform updates can introduce unexpected problems. A 481 Call/Transaction Does Not Exist response means the receiving system can no longer find the referenced call or transaction. During an attended transfer, this can happen when the transferor’s temporary call to the intended recipient (known as a consultation call) stays on hold long enough for a carrier device to expire it.

Platform changes matter too. In June 2026, Microsoft changed its blind-transfer behavior so its side ends the original call as soon as the SBC accepts the transfer, without waiting for the final result. Configurations that worked under the previous behavior may therefore need to be reviewed.

Practical troubleshooting checks

Start by identifying the transfer type (blind or attended), its direction, and which system receives the REFER request. Capture SIP traces of both a failed and successful transfer using SBC logs or a packet capture, then compare the messages to find where they differ.

Check whether REFER is listed in the Allow header on each leg of the call. If a system does not support REFER, removing it from the advertised methods may force some platforms to use INVITE with Replaces as a temporary workaround.

Next, verify that the new INVITE preserves the Refer-To and Referred-By values and that 202 Accepted and NOTIFY messages reach the system that initiated the transfer. Check message timing too, particularly whether a BYE arrives before the final NOTIFY. If callers hear silence instead of ringing, check REFER support and the handling of 180 Ringing and 183 Session Progress responses, which provide call-progress updates.

Also review firewall rules to ensure all required signaling addresses are allowed, and confirm that destination numbers use the format expected by the next system.
Finally, test internal and external transfers separately, including both blind and attended transfers across desk phones, softphones, and mobile devices. Comparing the results helps identify which system or network connection is causing the failure.

Call transfer failures between your phone system, carrier, or cloud platform can be difficult to diagnose. Our team can capture and analyze SIP traffic, identify where the handoff breaks, and help get your calls transferring reliably. Contact us to start troubleshooting.

When should a business retain or delete Microsoft 365 documents?

Editor November 9, 2026

Every document a business keeps carries both a cost and a risk. Keep records too briefly and the company may breach a legal requirement or lose evidence it needs. Keep everything forever and storage grows, searches slow down, and old content becomes a liability in a lawsuit or a data breach. Microsoft Purview lets administrators decide by rule what to keep, what to delete, and when. But deciding what to keep is only part of the equation; businesses also need a way to recover data when it is lost.

What retention rules actually do

Microsoft Purview provides the tools administrators use to control how long Microsoft 365 content is kept and when it should be deleted. It offers two basic retention actions: retain content so it cannot be permanently deleted, and delete it permanently. Combined, these produce three possible outcomes: retain only, delete only, or retain for a set period and then delete.

Content stays where it already lives, so people can continue working normally. If someone edits or deletes an item subject to retention, Microsoft quietly preserves a copy in a protected location, such as the Preservation Hold library for SharePoint and OneDrive or the Recoverable Items folder for Exchange mailboxes. Note that the Preservation Hold library counts toward a site’s storage quota, so retention can increase storage requirements.

Retention policies vs. retention labels

Administrators use two main tools to put retention requirements into practice: retention policies and retention labels. The difference is largely a matter of scope.

A retention policy applies the same set of rules to a broader location, such as a SharePoint site, Exchange mailbox, or Teams location. A retention label, by contrast, applies rules to an individual item, such as a document, folder, or email. This is useful when different records within the same location need different retention periods or treatment.

Labels also offer more flexibility in how retention periods are triggered. The clock can start when a label is applied or when a specific event occurs, such as an employee leaving or a contract expiring. They can also require a disposition review before content is permanently deleted.

The two tools often work together: policies establish the default retention rules for a location, while labels provide more specific instructions for individual records that need different treatment.

Setting retention periods based on requirements

Once retention policies and labels are in place, the next step is deciding how long content should be kept. Those periods should reflect legal, regulatory, and contractual obligations, not administrative convenience. For example, certain records may need to be retained for seven years under requirements such as the Sarbanes-Oxley Act. Tax, employment, healthcare, and client agreements may impose different timelines, so legal or compliance advisors should help determine the appropriate periods before retention settings are applied.

Beyond those requirements, avoid keeping content indefinitely without a clear business reason. Unnecessary records increase storage and e-discovery costs, expand the amount of data exposed in a breach, and make it harder to find relevant information.

How Purview resolves conflicting rules

A document or email may be covered by several retention policies and labels at the same time. When their instructions differ, Microsoft Purview uses four principles to determine what happens: retention takes precedence over deletion, the longest retention period wins, an explicit deletion instruction from a label takes precedence over an implicit deletion instruction from a policy, and the shortest deletion period applies among the remaining eligible rules.

For example, if an email is subject to a policy that deletes content after three years and a label that retains it for five years, Purview keeps it for five years before deletion. An eDiscovery hold takes precedence over these retention settings, although Microsoft advises against using holds for long-term life cycle management.

New retention settings can take up to seven days to take effect, so test them on a small group of sites or mailboxes before applying them across the organization.

Retention is not a backup

Retention policies and labels help organizations control how long Microsoft 365 content is kept for governance and compliance, but they are not designed for full data recovery. They do not create independent backup copies or point-in-time restore options. Recovering a lost folder may require searching protected locations or running an eDiscovery search rather than simply clicking Restore. More importantly, retention preserves content as users change or delete it; it does not provide a clean copy from before an incident such as ransomware or a mass deletion by a compromised account.

Recycle bins offer some short-term recovery, but their protection is limited. Deleted SharePoint and OneDrive items remain recoverable for about 93 days across both stages, while Exchange retains deleted items for 14 days by default, extendable to 30. Confirm these settings in your own tenant, as defaults may change. For more reliable recovery, organizations need an independent backup of their Microsoft 365 data, whether through Microsoft’s own backup service or a third-party solution.

A practical starting point

Start by identifying the main content types, mapping each to its legal, regulatory, or business requirements, and creating a small set of retention policies before introducing labels for more specific needs. Test the settings on one site or mailbox group, review the results with legal or compliance advisors, and expand gradually.

Take particular care with Preservation Lock: once enabled, it prevents anyone, including administrators, from modifying or removing the protected policy. Document the reasoning behind each decision and review the plan annually to keep pace with changing regulations and business needs.

Not sure how long your business should keep its Microsoft 365 documents, or whether your data is truly recoverable? Our team can review your retention settings, align them with your compliance needs, and set up backup that fills the gaps. Reach out to get started.

A practical guide to document life cycle management in Microsoft 365

Editor November 9, 2026

Many businesses assume that anything stored in Microsoft 365 is both safe and permanent. In reality, content is kept only for as long as the applicable retention settings require, and keeping information available is not the same as ensuring it can be recovered if something goes wrong. Understanding this distinction helps prevent costly surprises, whether a business needs to retrieve an important document or ensure that outdated content is properly removed.

What retention rules actually do

Microsoft Purview provides the tools administrators use to control how long Microsoft 365 content is kept and when it should be deleted. It offers two basic retention actions: retain content so it cannot be permanently deleted, and delete it permanently. Combined, these produce three possible outcomes: retain only, delete only, or retain for a set period and then delete.

Content stays where it already lives, so people can continue working normally. If someone edits or deletes an item subject to retention, Microsoft quietly preserves a copy in a protected location, such as the Preservation Hold library for SharePoint and OneDrive or the Recoverable Items folder for Exchange mailboxes. Note that the Preservation Hold library counts toward a site’s storage quota, so retention can increase storage requirements.

Retention policies vs. retention labels

Administrators use two main tools to put retention requirements into practice: retention policies and retention labels. The difference is largely a matter of scope.

A retention policy applies the same set of rules to a broader location, such as a SharePoint site, Exchange mailbox, or Teams location. A retention label, by contrast, applies rules to an individual item, such as a document, folder, or email. This is useful when different records within the same location need different retention periods or treatment.

Labels also offer more flexibility in how retention periods are triggered. The clock can start when a label is applied or when a specific event occurs, such as an employee leaving or a contract expiring. They can also require a disposition review before content is permanently deleted.

The two tools often work together: policies establish the default retention rules for a location, while labels provide more specific instructions for individual records that need different treatment.

Setting retention periods based on requirements

Once retention policies and labels are in place, the next step is deciding how long content should be kept. Those periods should reflect legal, regulatory, and contractual obligations, not administrative convenience. For example, certain records may need to be retained for seven years under requirements such as the Sarbanes-Oxley Act. Tax, employment, healthcare, and client agreements may impose different timelines, so legal or compliance advisors should help determine the appropriate periods before retention settings are applied.

Beyond those requirements, avoid keeping content indefinitely without a clear business reason. Unnecessary records increase storage and e-discovery costs, expand the amount of data exposed in a breach, and make it harder to find relevant information.

How Purview resolves conflicting rules

A document or email may be covered by several retention policies and labels at the same time. When their instructions differ, Microsoft Purview uses four principles to determine what happens: retention takes precedence over deletion, the longest retention period wins, an explicit deletion instruction from a label takes precedence over an implicit deletion instruction from a policy, and the shortest deletion period applies among the remaining eligible rules.

For example, if an email is subject to a policy that deletes content after three years and a label that retains it for five years, Purview keeps it for five years before deletion. An eDiscovery hold takes precedence over these retention settings, although Microsoft advises against using holds for long-term life cycle management.

New retention settings can take up to seven days to take effect, so test them on a small group of sites or mailboxes before applying them across the organization.

Retention is not a backup

Retention policies and labels help organizations control how long Microsoft 365 content is kept for governance and compliance, but they are not designed for full data recovery. They do not create independent backup copies or point-in-time restore options. Recovering a lost folder may require searching protected locations or running an eDiscovery search rather than simply clicking Restore. More importantly, retention preserves content as users change or delete it; it does not provide a clean copy from before an incident such as ransomware or a mass deletion by a compromised account.

Recycle bins offer some short-term recovery, but their protection is limited. Deleted SharePoint and OneDrive items remain recoverable for about 93 days across both stages, while Exchange retains deleted items for 14 days by default, extendable to 30. Confirm these settings in your own tenant, as defaults may change. For more reliable recovery, organizations need an independent backup of their Microsoft 365 data, whether through Microsoft’s own backup service or a third-party solution.

A practical starting point

Start by identifying the main content types, mapping each to its legal, regulatory, or business requirements, and creating a small set of retention policies before introducing labels for more specific needs. Test the settings on one site or mailbox group, review the results with legal or compliance advisors, and expand gradually.

Take particular care with Preservation Lock: once enabled, it prevents anyone, including administrators, from modifying or removing the protected policy. Document the reasoning behind each decision and review the plan annually to keep pace with changing regulations and business needs.

Not sure how long your business should keep its Microsoft 365 documents, or whether your data is truly recoverable? Our team can review your retention settings, align them with your compliance needs, and set up backup that fills the gaps. Reach out to get started.

Microsoft 365 retention explained: Policies, labels, and knowing when to let data go

Editor November 9, 2026

Microsoft 365 will keep or delete content automatically based on retention rules configured by administrators. Retention policies and labels turn legal, regulatory, and business requirements into settings that run quietly in the background. Getting them right means understanding how the rules interact, when deletion is appropriate, and why retention is a different thing from backup.

What retention rules actually do

Microsoft Purview provides the tools administrators use to control how long Microsoft 365 content is kept and when it should be deleted. It offers two basic retention actions: retain content so it cannot be permanently deleted, and delete it permanently. Combined, these produce three possible outcomes: retain only, delete only, or retain for a set period and then delete.

Content stays where it already lives, so people can continue working normally. If someone edits or deletes an item subject to retention, Microsoft quietly preserves a copy in a protected location, such as the Preservation Hold library for SharePoint and OneDrive or the Recoverable Items folder for Exchange mailboxes. Note that the Preservation Hold library counts toward a site’s storage quota, so retention can increase storage requirements.

Retention policies vs. retention labels

Administrators use two main tools to put retention requirements into practice: retention policies and retention labels. The difference is largely a matter of scope.

A retention policy applies the same set of rules to a broader location, such as a SharePoint site, Exchange mailbox, or Teams location. A retention label, by contrast, applies rules to an individual item, such as a document, folder, or email. This is useful when different records within the same location need different retention periods or treatment.

Labels also offer more flexibility in how retention periods are triggered. The clock can start when a label is applied or when a specific event occurs, such as an employee leaving or a contract expiring. They can also require a disposition review before content is permanently deleted.

The two tools often work together: policies establish the default retention rules for a location, while labels provide more specific instructions for individual records that need different treatment.

Setting retention periods based on requirements

Once retention policies and labels are in place, the next step is deciding how long content should be kept. Those periods should reflect legal, regulatory, and contractual obligations, not administrative convenience. For example, certain records may need to be retained for seven years under requirements such as the Sarbanes-Oxley Act. Tax, employment, healthcare, and client agreements may impose different timelines, so legal or compliance advisors should help determine the appropriate periods before retention settings are applied.

Beyond those requirements, avoid keeping content indefinitely without a clear business reason. Unnecessary records increase storage and e-discovery costs, expand the amount of data exposed in a breach, and make it harder to find relevant information.

How Purview resolves conflicting rules

A document or email may be covered by several retention policies and labels at the same time. When their instructions differ, Microsoft Purview uses four principles to determine what happens: retention takes precedence over deletion, the longest retention period wins, an explicit deletion instruction from a label takes precedence over an implicit deletion instruction from a policy, and the shortest deletion period applies among the remaining eligible rules.

For example, if an email is subject to a policy that deletes content after three years and a label that retains it for five years, Purview keeps it for five years before deletion. An eDiscovery hold takes precedence over these retention settings, although Microsoft advises against using holds for long-term life cycle management.

New retention settings can take up to seven days to take effect, so test them on a small group of sites or mailboxes before applying them across the organization.

Retention is not a backup

Retention policies and labels help organizations control how long Microsoft 365 content is kept for governance and compliance, but they are not designed for full data recovery. They do not create independent backup copies or point-in-time restore options. Recovering a lost folder may require searching protected locations or running an eDiscovery search rather than simply clicking Restore. More importantly, retention preserves content as users change or delete it; it does not provide a clean copy from before an incident such as ransomware or a mass deletion by a compromised account.

Recycle bins offer some short-term recovery, but their protection is limited. Deleted SharePoint and OneDrive items remain recoverable for about 93 days across both stages, while Exchange retains deleted items for 14 days by default, extendable to 30. Confirm these settings in your own tenant, as defaults may change. For more reliable recovery, organizations need an independent backup of their Microsoft 365 data, whether through Microsoft’s own backup service or a third-party solution.

A practical starting point

Start by identifying the main content types, mapping each to its legal, regulatory, or business requirements, and creating a small set of retention policies before introducing labels for more specific needs. Test the settings on one site or mailbox group, review the results with legal or compliance advisors, and expand gradually.

Take particular care with Preservation Lock: once enabled, it prevents anyone, including administrators, from modifying or removing the protected policy. Document the reasoning behind each decision and review the plan annually to keep pace with changing regulations and business needs.

Not sure how long your business should keep its Microsoft 365 documents, or whether your data is truly recoverable? Our team can review your retention settings, align them with your compliance needs, and set up backup that fills the gaps. Reach out to get started.

How dependencies shape business application availability

Editor November 6, 2026

Cloud application outages can stem from failures in supporting services and infrastructure. A failed sign-in may result from an authentication service outage, an inaccessible website from a DNS or network issue, and an unconfirmed order from a database or payment processing failure. Mapping these dependencies in advance and deciding how the application should respond when they become unavailable can prevent individual service failures from disrupting essential business operations.

Understanding hard and soft dependencies

In cloud application architecture, dependencies can be classified as hard or soft, depending on how essential they are to an application’s core functionality. A hard dependency is a service or component the application cannot function without. A soft dependency is one that can become unavailable without stopping the application’s essential functions, although some features may be limited or temporarily unavailable.

Applications should be designed to keep their essential functions running even when a supporting service becomes unavailable. For example, an online store should still allow customers to place orders if its product recommendation service goes down. Customers may lose personalized suggestions, but they should still be able to browse products and complete purchases.

Four dependencies that affect cloud application availability

There are four critical dependencies that require careful planning and management: identity providers, DNS, third-party APIs, and background processing systems.

Identity providers

Single sign-on makes it easier for employees to access multiple applications with one set of login credentials. However, if the identity provider responsible for verifying those credentials becomes unavailable, employees may lose access to applications that are otherwise working normally. Employees who are already signed in may also lose access when their login sessions expire.

To reduce disruption, set session durations carefully so employees are not all forced to sign in again during a brief service outage. Balance this with security requirements. Also, maintain a small number of emergency administrator accounts that can be accessed independently of the main sign-in service. Protect these accounts with strong multifactor authentication and test them regularly to ensure they work when needed.

DNS

DNS (Domain Name System) helps users and applications find websites and online services by translating domain names into the addresses computers use to connect. If DNS stops working, users may be unable to reach websites even when the servers hosting them are still running. Applications may also lose access to other services they depend on.

To reduce this risk, consider using a backup DNS provider for important domains so another provider can take over if the primary one fails. Set DNS record update times (known as time-to-live or TTL values) to allow changes to take effect within an appropriate timeframe. Secure your domain registrar account, keep track of renewal dates, and make sure designated team members know how to update DNS records during an emergency and where to access the required credentials.

Third-party APIs

Payment processors, shipping services, messaging platforms, and mapping tools often rely on external services to provide essential features. If one of these services responds slowly or stops working, the application may struggle to complete tasks that depend on it. A slow response can be particularly disruptive because the application may continue waiting, tying up resources that other users need.

To limit the impact, configure time limits so the application does not wait indefinitely for an external service. Limit the number of automatic retries and use a circuit breaker, which temporarily stops requests to a service that is repeatedly failing. Where possible, provide an alternative result rather than leaving users waiting.

For example, a travel booking platform could display previously retrieved hotel availability information while a hotel provider’s API is temporarily unavailable, rather than leaving users waiting for the page to load. Keep these alternatives simple and avoid complicated workarounds that introduce additional dependencies or potential points of failure.

Background processing

Queues and background jobs let applications handle tasks without making users wait. For example, an employee management system can save a leave request immediately while processing approval notifications or updating payroll records in the background. However, if a service needed to complete these tasks becomes unavailable, unfinished work can pile up. Repeated retries can make the backlog worse and overwhelm the service when it recovers.

To limit disruption, set limits on automatic retries and the number of tasks waiting in a queue. Use a dead letter queue (DLQ), a separate holding area for tasks that repeatedly fail, so they can be investigated and processed later without blocking other work. Keep essential user-facing functions running independently of background tasks, and identify which jobs must be completed promptly and which can safely wait.

Map the chain and rehearse the failures

For each critical application, identify the services it relies on, then determine which services are essential for the application to function and which can become unavailable without stopping its core features. Document what users would experience if each service failed and test whether the application can continue operating under those conditions.

A common mistake is failing to identify which application functions are essential to business operations or assuming they will continue working when a supporting service fails without testing them. Businesses that rely on Software-as-a-Service (SaaS) products should also ask vendors about their service dependencies, outage procedures, and availability commitments, and include this information in vendor assessments.

If you’re unsure how exposed your business applications are to a single failing service, we can help. Our team can map your critical dependencies, identify the weak points, , and help you plan how to keep essential application features available during an outage. Contact us to start the review.

How cloud dependencies affect application availability during an outage

Editor November 6, 2026

When a cloud application becomes unavailable, the cause may lie in a service it depends on rather than in the application itself. Identity providers, DNS, third-party APIs, and background processing all play a role in delivering a working service to users. Identifying which dependencies are essential to business operations helps organizations prepare for service disruptions and keep critical application functions running.

Understanding hard and soft dependencies

In cloud application architecture, dependencies can be classified as hard or soft, depending on how essential they are to an application’s core functionality. A hard dependency is a service or component the application cannot function without. A soft dependency is one that can become unavailable without stopping the application’s essential functions, although some features may be limited or temporarily unavailable.

Applications should be designed to keep their essential functions running even when a supporting service becomes unavailable. For example, an online store should still allow customers to place orders if its product recommendation service goes down. Customers may lose personalized suggestions, but they should still be able to browse products and complete purchases.

Four dependencies that affect cloud application availability

There are four critical dependencies that require careful planning and management: identity providers, DNS, third-party APIs, and background processing systems.

Identity providers

Single sign-on makes it easier for employees to access multiple applications with one set of login credentials. However, if the identity provider responsible for verifying those credentials becomes unavailable, employees may lose access to applications that are otherwise working normally. Employees who are already signed in may also lose access when their login sessions expire.

To reduce disruption, set session durations carefully so employees are not all forced to sign in again during a brief service outage. Balance this with security requirements. Also, maintain a small number of emergency administrator accounts that can be accessed independently of the main sign-in service. Protect these accounts with strong multifactor authentication and test them regularly to ensure they work when needed.

DNS

DNS (Domain Name System) helps users and applications find websites and online services by translating domain names into the addresses computers use to connect. If DNS stops working, users may be unable to reach websites even when the servers hosting them are still running. Applications may also lose access to other services they depend on.

To reduce this risk, consider using a backup DNS provider for important domains so another provider can take over if the primary one fails. Set DNS record update times (known as time-to-live or TTL values) to allow changes to take effect within an appropriate timeframe. Secure your domain registrar account, keep track of renewal dates, and make sure designated team members know how to update DNS records during an emergency and where to access the required credentials.

Third-party APIs

Payment processors, shipping services, messaging platforms, and mapping tools often rely on external services to provide essential features. If one of these services responds slowly or stops working, the application may struggle to complete tasks that depend on it. A slow response can be particularly disruptive because the application may continue waiting, tying up resources that other users need.

To limit the impact, configure time limits so the application does not wait indefinitely for an external service. Limit the number of automatic retries and use a circuit breaker, which temporarily stops requests to a service that is repeatedly failing. Where possible, provide an alternative result rather than leaving users waiting.

For example, a travel booking platform could display previously retrieved hotel availability information while a hotel provider’s API is temporarily unavailable, rather than leaving users waiting for the page to load. Keep these alternatives simple and avoid complicated workarounds that introduce additional dependencies or potential points of failure.

Background processing

Queues and background jobs let applications handle tasks without making users wait. For example, an employee management system can save a leave request immediately while processing approval notifications or updating payroll records in the background. However, if a service needed to complete these tasks becomes unavailable, unfinished work can pile up. Repeated retries can make the backlog worse and overwhelm the service when it recovers.

To limit disruption, set limits on automatic retries and the number of tasks waiting in a queue. Use a dead letter queue (DLQ), a separate holding area for tasks that repeatedly fail, so they can be investigated and processed later without blocking other work. Keep essential user-facing functions running independently of background tasks, and identify which jobs must be completed promptly and which can safely wait.

Map the chain and rehearse the failures

For each critical application, identify the services it relies on, then determine which services are essential for the application to function and which can become unavailable without stopping its core features. Document what users would experience if each service failed and test whether the application can continue operating under those conditions.

A common mistake is failing to identify which application functions are essential to business operations or assuming they will continue working when a supporting service fails without testing them. Businesses that rely on Software-as-a-Service (SaaS) products should also ask vendors about their service dependencies, outage procedures, and availability commitments, and include this information in vendor assessments.

If you’re unsure how exposed your business applications are to a single failing service, we can help. Our team can map your critical dependencies, identify the weak points, , and help you plan how to keep essential application features available during an outage. Contact us to start the review.

Why cloud application dependencies matter during an outage

Editor November 6, 2026

A business application can become unavailable even when its core systems are working. A failed identity provider, DNS resolution issue, unresponsive payment API, or backed-up job queue can prevent users from completing essential tasks. These services are dependencies that applications rely on to function. Understanding which dependencies are critical to business operations is essential to maintaining availability when individual services fail.

Understanding hard and soft dependencies

In cloud application architecture, dependencies can be classified as hard or soft, depending on how essential they are to an application’s core functionality. A hard dependency is a service or component the application cannot function without. A soft dependency is one that can become unavailable without stopping the application’s essential functions, although some features may be limited or temporarily unavailable.

Applications should be designed to keep their essential functions running even when a supporting service becomes unavailable. For example, an online store should still allow customers to place orders if its product recommendation service goes down. Customers may lose personalized suggestions, but they should still be able to browse products and complete purchases.

Four dependencies that affect cloud application availability

There are four critical dependencies that require careful planning and management: identity providers, DNS, third-party APIs, and background processing systems.

Identity providers

Single sign-on makes it easier for employees to access multiple applications with one set of login credentials. However, if the identity provider responsible for verifying those credentials becomes unavailable, employees may lose access to applications that are otherwise working normally. Employees who are already signed in may also lose access when their login sessions expire.

To reduce disruption, set session durations carefully so employees are not all forced to sign in again during a brief service outage. Balance this with security requirements. Also, maintain a small number of emergency administrator accounts that can be accessed independently of the main sign-in service. Protect these accounts with strong multifactor authentication and test them regularly to ensure they work when needed.

DNS

DNS (Domain Name System) helps users and applications find websites and online services by translating domain names into the addresses computers use to connect. If DNS stops working, users may be unable to reach websites even when the servers hosting them are still running. Applications may also lose access to other services they depend on.

To reduce this risk, consider using a backup DNS provider for important domains so another provider can take over if the primary one fails. Set DNS record update times (known as time-to-live or TTL values) to allow changes to take effect within an appropriate timeframe. Secure your domain registrar account, keep track of renewal dates, and make sure designated team members know how to update DNS records during an emergency and where to access the required credentials.

Third-party APIs

Payment processors, shipping services, messaging platforms, and mapping tools often rely on external services to provide essential features. If one of these services responds slowly or stops working, the application may struggle to complete tasks that depend on it. A slow response can be particularly disruptive because the application may continue waiting, tying up resources that other users need.

To limit the impact, configure time limits so the application does not wait indefinitely for an external service. Limit the number of automatic retries and use a circuit breaker, which temporarily stops requests to a service that is repeatedly failing. Where possible, provide an alternative result rather than leaving users waiting.

For example, a travel booking platform could display previously retrieved hotel availability information while a hotel provider’s API is temporarily unavailable, rather than leaving users waiting for the page to load. Keep these alternatives simple and avoid complicated workarounds that introduce additional dependencies or potential points of failure.

Background processing

Queues and background jobs let applications handle tasks without making users wait. For example, an employee management system can save a leave request immediately while processing approval notifications or updating payroll records in the background. However, if a service needed to complete these tasks becomes unavailable, unfinished work can pile up. Repeated retries can make the backlog worse and overwhelm the service when it recovers.

To limit disruption, set limits on automatic retries and the number of tasks waiting in a queue. Use a dead letter queue (DLQ), a separate holding area for tasks that repeatedly fail, so they can be investigated and processed later without blocking other work. Keep essential user-facing functions running independently of background tasks, and identify which jobs must be completed promptly and which can safely wait.

Map the chain and rehearse the failures

For each critical application, identify the services it relies on, then determine which services are essential for the application to function and which can become unavailable without stopping its core features. Document what users would experience if each service failed and test whether the application can continue operating under those conditions.

A common mistake is failing to identify which application functions are essential to business operations or assuming they will continue working when a supporting service fails without testing them. Businesses that rely on Software-as-a-Service (SaaS) products should also ask vendors about their service dependencies, outage procedures, and availability commitments, and include this information in vendor assessments.

If you’re unsure how exposed your business applications are to a single failing service, we can help. Our team can map your critical dependencies, identify the weak points, , and help you plan how to keep essential application features available during an outage. Contact us to start the review.

Beyond the password handoff: Preserving institutional knowledge before an IT departure

Editor November 4, 2026

Every business has at least one person who knows why things are configured the way they are. Until that knowledge is written down, it belongs to the individual rather than the company. Keeping a simple log of technology decisions turns individual knowledge into a shared reference material and makes leadership transitions far smoother.

What access handoffs leave out

NIST SP 800-53 addresses employee departures through personnel termination control PS-4. It calls for disabling system access, conducting exit interviews, retrieving security-related property, and ensuring continued access to the information and systems the departing employee managed.
These steps are important, but they protect access rather than preserve institutional knowledge. A business can retain every credential and still not know why an exception was granted, which integration is fragile, or when a critical domain needs renewal.

What an IT decision log contains

An IT decision log is a running record of significant technology decisions, with one entry for each major choice. Each entry should be brief, usually about half a page, and cover a few key points: what was decided and when, who is responsible, which alternatives were considered, why the option was chosen, what risks were accepted, and when the decision should be reviewed. Examples include choosing a backup product, granting a permanent firewall exception, or standardizing on an email platform.
A sample entry might look like this:

  • Decision: Moved off-site backups to a second cloud provider
  • Owner: IT manager, with the operations lead as backup
  • Alternatives considered: Tape rotation and replication with the same provider
  • Reason for decision: A single-provider outage could affect both primary and backup copies
  • Dependencies: A service account in the identity provider and a nightly backup job at 2:00 a.m.
  • Review date: 12 months

Store the log in a shared, access-controlled location with regular backups. Keeping it in a personal notebook or on a single employee’s drive defeats its purpose.

Document dependencies alongside decisions

Decisions rarely stand alone, so each entry should note what depends on it. Record which systems rely on which, where service accounts and API keys are used, who holds administrator access and where recovery codes are stored, and which vendors, licenses, and domains renew on what dates. A separate one-page dependency map for the five or six most critical systems is often more useful in a crisis than a long policy document.

Make the habit routine, not a cleanup project

Waiting until an employee gives notice to document their decisions leaves little time to capture everything accurately. To avoid this, add an entry whenever a change is approved and review the log quarterly. Make documentation part of existing routines by including a log update in the change approval process and adding a step to the offboarding checklist to confirm that the departing employee’s decisions and dependencies have been recorded.

How a log simplifies leadership transitions

New IT managers, incoming business owners, and replacement service providers often face the same challenge: inheriting a working IT environment without knowing its history. A decision log helps shorten the learning curve and prevents past decisions from being reversed without understanding the reasons behind them. It also makes it easier to respond to cyber insurance questionnaires, audits, and vendor reviews because the relevant decisions and reasoning are already documented.

A practical way to begin

If no log exists, start small. Identify the most critical systems, then schedule a 30-minute conversation with the person who knows each system best. Use these conversations to document key decisions and dependencies. Prioritize employees who may leave soon and systems with little existing documentation. A simple shared template and monthly reminder can help keep the process going.
If you’re concerned about what your business would lose if a key IT person left tomorrow, our team can help. We’ll guide you in building a decision log, mapping your critical dependencies, and putting a practical knowledge transfer process in place. Reach out to get started.

Website Management for Small Business Owners

Full-service, pay-as-you-go WordPress websites, from design and content to SEO and Google Ads management for an affordable monthly price.

Learn more about our website management services for small businesses.

Search
Archives