Incremental Deprecation

Deprecate incrementally along with incremental releases to save cost, avoid tech debt and more, all in today's article.

We all know how to release new features and services incrementally in a big migration project, but most of the time we don’t really care about the other side which is deprecation. In this article, I will share how deprecating incrementally with parallel releases can bring tremendous benefits.

Release X → Run in Parallel → Deprecate X

Deprecation should be part of design/plan/migration document and communicated to users from the beginning to make the most of it. A typical migration flow will look like:

Release X → Run in Parallel → Deprecate X

📖Related Reading: Large Scale Migration Best Practices

Lets dive:

Save Cost

Running two End to End Systems in parallel can be very expensive, this can be estimated early on to decide whether incremental deprecation would save meaningful $ or not. A big data heavy project are typically expensive, and its well worth to consider the proposed approach.

💡Cost will still be high for the time being especially during the mini parallel runs which is required for testing and validation.

Avoid Tech Debt

Ignoring the deprecation planning would lead to unnecessary technical debt which itself is a very challenging problem to solve, it is better to avoid its in first place. Read how to deal it by considering Tech Debt as a Financial Debt.

💡This makes the architecture and codebase clean and healthy from the beginning.

Easier Rollbacks

Rollbacks are needed when something does not work as expected, with incremental deprecation you have the power to easily rollback. Consider from the image above, if you Deprecated A and for some reason Release A did not work as expected, you could easily and quickly revert.

💡This is the same approach used in incremental releases.

Quicker Feedback

Incremental deprecation also pushes users to move to new systems quickly to try, test and provide feedback. Keeping the old service alive till the end could mean users have the opportunity to stay at old service until the whole system is shutdown.

💡Moving users and dependencies to newer service is a very common challenge.

---

This is something I shared on LinkedIn a year ago:

---

⭐ Special Recommendation: Architecture Notes by

Mahdi Yusuf

is now on Substack.

In case you missed a guest post by

Vu Trinh

earlier this week, give it a read and provide feedback.

From Around:

• If you like to quickly grow your career, show love for: The Hight Growth Engineer by

  Jordan Cutler

• If you are interested in reading more about Venture Capital, visit: The VC Corner by

  Ruben Dominguez Ibar

• If you like to understand how modern scalable systems work, check out: System Design by

  Neo Kim

• If you love practical coding, head to: Coding Challenges by

  John Crickett

---