Verificando autenticación…

Skip to main content

Deprecation Schedule

An application's lifecycle does not end with deployment; it also includes its eventual retirement. A well-planned deprecation strategy is crucial to minimize impact on users and other systems, and to ensure an orderly transition.

When to Deprecate an Application?

An application or service is a candidate for deprecation when:

  • It has been replaced by a more modern and efficient solution.
  • The technology it is based on has become obsolete and presents security or maintenance risks.
  • It no longer aligns with the company's business objectives.
  • Its usage has decreased significantly and the cost of maintaining it is no longer justified.

Deprecation Process

Once the decision has been made to deprecate a service, we follow a structured process:

  1. Impact Analysis (Duration: 1-2 weeks):

    • Identify Dependencies: Perform a thorough analysis to identify all systems and users that consume the service. Monitoring tools and logs are essential at this stage.
    • Assess Impact: Determine the impact that deprecation will have on each consumer.
  2. Planning and Communication (Duration: 1 week):

    • Define the Migration Strategy: Create a detailed plan describing alternatives to the deprecated service and the steps consumers must follow to migrate.
    • Establish a Timeline: Define clear dates for each phase of the deprecation process (announcement, brownout, shutdown date).
    • Initial Communication: Notify all stakeholders and affected teams about the deprecation plan. Communication should be clear, concise, and provide all necessary information.
  3. Migration Period (Duration: 3-6 months, depending on complexity):

    • Migration Support: The service owner team must provide active support to consumer teams during their migration process.
    • Progress Monitoring: Track the migration progress of each consumer.
    • Brownouts (Scheduled Outages): Perform temporary, controlled outages of the legacy service. This helps identify dependencies that were not detected in the initial analysis and motivates teams to accelerate their migration. Brownout dates and times must be communicated in advance.
  4. Deprecation Execution (D-Day):

    • Service Shutdown: On the scheduled date, the service is disabled. It is not completely removed immediately.
    • Post-Shutdown Monitoring: Closely monitor systems to detect any unexpected impact.
  5. Post-Deprecation:

    • Final Communication: Announce that the service has been successfully deprecated.
    • Archiving: After a grace period (e.g., 1 month) to ensure there are no residual impacts, proceed with archiving the code and infrastructure.