Sagar Kulkarni

  • Future proofing systems: Migration, Modernization & Technical Debt – A perspective

    Being honest,

    Modernization sounds exciting on paper. Migrate the legacy, refactor the code, adopt the cloud, introduce microservices, and automate everything. But when you are in the actual game of change, it is not all about trends. It’s about intentional design, risk-managed decisions, opportunities, and future proofing with purpose.

    • Migration (from legacy to modern)
    • Modernization (redefining how the system works)
    • Technical Debt (the often-ignored iceberg under the surface)

    My views on how to think about these together not just to catch up with today, but to stay relevant 10+ years down the line.

    Migration, modernization, and technical debt are not three separate problems or issues😊. They’re the same problem, viewed from different angles.

    All my view is part of my experience with migration, modernization, tech debt, and part of lessons from books I regard (like Architecture Modernization by Nick Tune, Software Architecture: The Hard Parts by Neal Ford, and Building Evolutionary Architectures by Rebecca Parsons). I am trying to put my views, just the way I came to think about building systems that don’t fall with the next framework trend.

    Modernization, glossy new tech stack

    When we say “modernize,” we often mean “rewrite everything with a new stack.” Angular to React, Java to Go, monolith to microservices, on-prem to cloud, and so on… I am sure many of you are going through similar journeys and thoughts. Often mistakenly understood as throwing away legacy code for the sake of rewriting everything in a modern stack.

    Modernization Is About Rethinking, Not Rewriting

    “Modernization is not upgrading for the sake of upgrading. It’s about enabling systems to change with less friction.” — Architecture Modernization (Tune & Barmash)

    Real modernization is when: (priority order may vary)

    • Redefine user journeys, and workflows backed by user research
    • New developers can start without decoding specific knowledge.
    • Refactor core workflows without affecting everywhere.
    • System tolerates mistakes, changes gracefully, and scales.
    • Reducing system instability
    • Increasing adaptability to change
    • Avoiding irreversible complexity
    • How easy is it to change this system in 5 years?
    • Is core business rules visible and testable?
    • Keeping some parts of the legacy system that still work well, provided the platform, libraries, language, and core still exist and are supported. Some exception examples can be – Applet, Flex, Durandal, knockout js. etc. this must be under sunset, unless you are sure that you
    • Prioritize what to modernize based on business value and rate of change.

    Modernization is evolution not revolution. Again, I would like to quote the thought from Architecture Modernization; many confuse modernization with technology refresh.

    “Just because it’s new doesn’t mean it’s better. The goal is to make systems sustainable, not trendy.”

    Moving to migration, it is not like a moving truck

    As far as I have experienced, migration is often treated like logistics just move the system from one home to another. Cloud migration is a classic and typical example. But if you are migrating legacy systems and not questioning what’s inside, it is like carrying debt into a bigger room. Example – moving your monolith from on-prem to AWS. That’s logistics, not transformation. It’s not about lifting and shifting. It’s about real transformation with value, not just relocation.

    Books like Building Evolutionary Architectures recommend gradual migrations using strangler patterns, backward-compatible interfaces, and fitness functions that will measure whether the system is actually improving during the change and adding real value to the current state.

    As described in Building Evolutionary Architectures, migrations must support incremental adaptability. In real projects, this means:

    • Introducing strangler fig patterns to migrate module-by-module
    • Building backward compatible APIs to avoid Big Bangs
    • Using fitness functions (automated rules to preserve architecture goals)

    “If migration is just moving the mess from one room to another, it’s not migration it’s relocation.”

    Next is technical Debt, which is again misunderstood. It’s not always messy code. It can also be:

    • Outdated architecture that struggles to change
    • Unstable tests that block refactoring
    • Outdated platforms, libraries, or languages

    “You cannot modernize around technical debt. It must be part of the plan.”  Architecture Modernization

    Debt slows down teams, frustrates developers, and increases the cost of future changes. Every modernization effort must address debt explicitly. Otherwise, it’s like repainting cracked walls.

    Finally future proofing is about Design, not Predictions

    In my opinion, so what does it really mean to future-proof a system? These are principles I have tried adopting (and learned sometimes the hard way)

    Some ideas which I thought of adding it here, I believe that have worked for me:

    • User experience, may it be internal system user or customer facing Keep doors open for workflow and user journey changes.
    • Design for change, not just today’s load. Decouple. Modularize. Always think about replaceable boundaries.
    • Expose business logic. If your core business rules are hidden under n’ layers of frameworks, no one will touch them for years from now.
    • Automate where it hurts the most. Tests, deployments, monitoring. Every bit of automation pays off when systems evolve. Observability, CI/CD, IaC, test automation it all reduces future risk.
    • Stabilize APIs. Version slowly. Avoid breaking contracts. Make the system predictable for those outside your team.
    • Don’t rewrite what works. Martin Fowler’s philosophy on refactoring still holds: clean what you need, evolve the rest.

    ·        Think 10 years ahead What tech will outlast trends? It’s very complex and hard to achieve, especially during the AI era, but still designed around it with adaptability. Again, as I said at the beginning of this post, trends are not important, but still, when you are on your journey, adopt them wisely.

    So just my reference I created the following guidelines,

    Evolving Core Principle

    Modularity

    Decompose the system into clear, replaceable services or modules.

    Encapsulation

    Keep domain logic isolated from infrastructure concerns.

    Interface Stability

    Expose functionality through APIs with versioning and contract testing.

    Dependency Control

    Use event-driven or asynchronous messaging to reduce tight coupling.

    Incremental Migration

    Apply patterns like Strangler Fig to evolve parts of the core safely.

    Observability

    Ensure metrics and logs allow visibility into both old and new components.

    Fitness Functions

    Automate checks to keep architecture aligned as it evolves.

    User experience

    Doors are always open for user journey and workflow changes.

    Also always keeping the following list of few antipatterns handy to prevent,

    • “Big Ball of Mud” Core : Where everything depends on everything else.
    • “Rewrite to Survive” Mentality: Systems are abandoned instead of improved.
    • “Silent Decay” :Teams avoid the core entirely, allowing it to rot.
    • “Hidden Domain Logic” : Business-critical logic buried deep in inaccessible code.

    Final thoughts,

    After lengthy post, I believe, modernization, migration or tech debt any of this is a amazing journey, not a single project that you deliver. It is not once, its like building systems that can adopt themselves gradually.

    Future proofing is an enterprise mindset. It’s not about the tech stack selection. It’s about how design changes with value, controlling debt without losing control over it, and managing evolution.

    What’s your experience with modernization and tech debt?

    Let’s open the conversation. Have you dealt with a Big Bang migration? How do you handle tech debt cleanup while still delivering features?

    I would like to hear your views, especially from teams navigating these challenges in fintech, healthcare, and other fast-changing domains.

  • When Blue Ocean Meets Platform Thinking: My Unfinished Thoughts on “winning without competition?”

    So, here is the thing. I read Blue Ocean Strategy (Renee A. Mauborgne , W. Chan Kim ) a few years ago, and then recently, I went through The Platform Mindset (Marcus Fontoura). Both are different books, and set of theories written for different kinds of people, but I love smashing ideas together like lego bricks. So, I started thinking ”what happens when you mix these two concepts?”

    At first, they seem different. Blue Ocean Strategy says, “Avoid competition by creating something new.” The Platform Mindset says, “Don’t just create— build something that enables others to create.”

    The Blue Ocean Strategy talks about escaping the red oceans, where everyone fights each other over the same customers, and instead, creating new, uncontested spaces. Meanwhile, the Platform Mindset talks about not just making a product but building a whole ecosystem around it. So, what if you don’t just create a new ocean but also build the boats, the docks, and the entire marketplace around it?  That’s where I keep circling back.

    Is this an Illusion of Competition?

    If you look at most businesses, they fight over the same customers with slightly better features, lower prices, and aggressive marketing. Typically, classic red ocean. But real value is not created by fighting its created by defining and changing the rules of the game. But think a while, what if you change the game AND own the playground? I believe that’s where the platform thinking comes in.

    Now let’s look at Amazon AWS. They also started with a blue ocean cloud computing at scale, pay-as-you-go. But they didn’t stop at just offering cloud services. They built a ultimate platform an ecosystem of compute power, databases, AI tools, analytics, and serverless functions. You don’t just use AWS; you build on and around AWS.

    That’s the key difference. A blue ocean alone can be copied. But a platform blue ocean is hard to replicate

    I think most platforms don’t compete each other. They enable others to compete on their terms. Apple App Store doesn’t care if your app is better than the next one it just wants more apps. Amazon Marketplace doesn’t fight individual sellers; it gives them a place to fight each other while taking a cut from every sale. And I think that’s a platform mindset. But if you do this in a blue ocean way, you don’t just enable competition you redefine what success even looks like.

    In my opinion “How Blue Ocean Thinking and Platforms Can Work Together?”

    Most blue ocean thinkers build a single thing typically a new product, a new service, a new way to solve a problem. But what if, instead of stopping at a product, you built a whole new way of operating? If we take example of Tesla, they didn’t just make electric cars. It made charging networks, software updates, and energy grids etc. a whole platform around cars.

    And there are many such.

    Thats the missing link, which I thought of. A true blue ocean is not just about making something new but making something that others can build upon. A platform-first blue ocean just not about innovation its about enabling infinite innovation.

    The Struggle: When Blue Ocean Thinking Goes Wrong

    Of course, not everything works, which I strongly believe, 😊 but at the same time, there is a  lot of learning, too. Thinking that we are creating blue oceans, but end up building a glorified feature inside someone else’s platform. So, I think the trick is balance. A blue ocean platform should give people the tools to build but should also set the rules so that you don’t become just another app inside someone else’s bigger game.

    My Own Platform-Blue-Ocean struggle will continue. Am I making a product? Or am I making a system where people can create value? The best ideas seem to lean towards the latter.

    If I had to conclude this messy thought process into one line, it would be:

    The best way to escape competition and excel is not just to create something new, but to create something that others can build upon. That’s the kind of game worth playing.

    What do you think? Does this make sense? Or have I just spent too much time smashing different ideas together unnecessarily? 😊 Please add your thoughts, reference etc. in comments.

    #Blue Ocean #PlatformThinking #PlatformMindset #