Return to Answer

It's the answer when the rewrite allows the organization to pursue a business strategy that affords a competitive edge or allows it to better serve its customers in some manner that the current architecture cannot accommodate.

Instead, rewrites often happen to alleviate management worries:

• everything should be in .NET,
• our developers say our code sucks,
• we're falling behind technically,
• we won't be able to find resources to support our system or, very often,
• it's been ten years so it's time.

Most of these worries won't materialize and, if they did, they could be handled. That last one, however, is the worst. It's essentially: we don't have a reason.

Yes, like car, a system will begin to show signs of wear. This can be alleviated by routine servicing. You know what they say about how a little preventative maintenance goes a long way. As an investment, routine servicing (i.e. refactoring and standardizing) will almost always carry less cost than a rewrite.

However, we have to anticipate that a rewrite will eventually be necessary. Set dates and tentatively plan for it, but as the date draws nearer assess its actual necessity/worth and bump out the dates in favor of realizing other strategic goals.

Hold out for a good strategic reason like this:

In recent years we've lost the opportunity to win big accounts because we couldn't accommodate their needs in a timely or costly fashion. Our system will be rewritten using an extensible architecture that allows customizations to be plugged in (and not hardcoded as we currently do). This will dramatically decrease the time and cost of accommodating customers with special needs. We'll win more accounts and better meet the needs of our current customers.

It's the answer when the rewrite allows the organization to pursue a strategy that affords a competitive edge or allows it to better serve its customers in some manner that the current architecture cannot accommodate.

Instead, rewrites often happen to alleviate management worries:

• everything should be in .NET,
• our developers say our code sucks,
• we're falling behind technically,
• we won't be able to find resources to support our system or, very often,
• it's been ten years so it's time.

Most of these worries won't materialize and, if they did, they could be handled. That last one, however, is the worst. It's essentially: we don't have a reason.

Yes, like car, a system will begin to show signs of wear. This can be alleviated by routine servicing. You know what they say about how a little preventative maintenance goes a long way. As an investment, routine servicing (i.e. refactoring and standardizing) will almost always carry less cost than a rewrite.

However, we have to anticipate that a rewrite will eventually be necessary. Set dates and tentatively plan for it, but as the date draws nearer delay in favor of realizing other strategic goals until you have a compelling reason like...

In recent years we've lost the opportunity to win big accounts because we couldn't accommodate their needs in a timely or costly fashion. Our system will be rewritten using an extensible architecture that allows customizations to be plugged in (and not hardcoded as we currently do). This will dramatically decrease the time and cost of accommodating customers with special needs. We'll win more accounts and better meet the needs of our current customers.

It's the answer when the rewrite allows the organization to pursue a business strategy that affords a competitive edge or allows it to better serve its customers in some manner that the current system cannot accommodate.

Instead, rewrites often happen to alleviate management worries:

• everything should be in .NET,
• our developers say our code sucks,
• we're falling behind technically,
• we won't be able to find resources to support our system or, very often,
• it's been ten years so it's time.

Most of these worries won't materialize and, if they did, they could be handled. That last one, however, is the worst. It's essentially: we don't have a reason.

Yes, like car, a system will begin to show signs of wear. This can be alleviated by routine servicing. You know what they say about how a little preventative maintenance goes a long way. As an investment, routine servicing (i.e. refactoring and standardizing) will almost always be less costly than a rewrite.

However, we have to anticipate that a rewrite will eventually be necessary. Set dates and tentatively plan for it, but as the date draws nearer assess its actual necessity/worth and bump out the dates in favor of realizing other strategic goals.

Hold out for a good strategic reason like this:

In recent years we've lost the opportunity to win big accounts because we couldn't accommodate their needs in a timely or costly fashion. Our system will be rewritten using an extensible architecture that allows customizations to be plugged in (and not hardcoded as we currently do). This will dramatically decrease the time and cost of accommodating customers with special needs. We'll win more accounts and better meet the needs of our current customers.

It's the answer when the rewrite allows the organization to pursue a business strategy that affords a competitive edge or allows it to better serve its customers in some manner that the current architecture cannot accommodate.

Instead, rewrites often happen to alleviate management worries:

• everything should be in .NET,
• our developers say our code sucks,
• we're falling behind technically,
• we won't be able to find resources to support our system or, very often,
• it's been ten years so it's time.

Most of these worries won't materialize and, if they did, they could be handled. That last one, however, is the worst. It's essentially: we don't have a reason.

Yes, like car, a system will begin to show signs of wear. This can be alleviated by routine servicing. You know what they say about how a little preventative maintenance goes a long way. As an investment, routine servicing (i.e. refactoring and standardizing) will almost always carry less cost than a rewrite.

However, we have to anticipate that a rewrite will eventually be necessary. Set dates and tentatively plan for it, but as the date draws nearer assess its actual necessity/worth and bump out the dates in favor of realizing other strategic goals.

Hold out for a good strategic reason like this:

In recent years we've lost the opportunity to win big accounts because we couldn't accommodate their needs in a timely or costly fashion. Our system will be rewritten using an extensible architecture that allows customizations to be plugged in (and not hardcoded as we currently do). This will dramatically decrease the time and cost of accommodating customers with special needs. We'll win more accounts and better meet the needs of our current customers.

It's the answer when the rewrite allows the organization to pursue a business strategy that affords a competitive edge or allows it to better serve its customers in some manner that the current system cannot accommodate.

Instead, rewrites often happen to alleviate management worries:

• everything should be in .NET,
• our developers say our code sucks,
• we're falling behind technically,
• we won't be able to find resources to support our system or, very often,
• it's been ten years so it's time.

Most of these worries won't materialize and, if they did, they could be handled. That last one, however, is the worst. It's essentially: we don't have a reason.

Yes, like car, a system will begin to show signs of wear. This can be alleviated by routine servicing. You know what they say about how a little preventative maintenance goes a long way. As an investment, paying down technical debt will almost always financially outperform the rewrite.

However, we have to anticipate that a rewrite will eventually be necessary. Set tentative dates and plan for it, but as the date draws nearer assess its actual necessity and bump out the dates in favor of realizing other strategic goals. Without a strategic reason, there's a greater incentive to postpone than not.

This is the kind of reason you wait on:

In recent years we've lost the opportunity to win big accounts because we couldn't accommodate their needs in a timely or costly fashion. Our system will be rewritten using an extensible architecture that allows customizations to be plugged in (and not hardcoded as we currently do). This will dramatically decrease the time and cost of accommodating customers with special needs.

It's the answer when the rewrite allows the organization to pursue a business strategy that affords a competitive edge or allows it to better serve its customers in some manner that the current system cannot accommodate.

Instead, rewrites often happen to alleviate management worries:

• everything should be in .NET,
• our developers say our code sucks,
• we're falling behind technically,
• we won't be able to find resources to support our system or, very often,
• it's been ten years so it's time.

Most of these worries won't materialize and, if they did, they could be handled. That last one, however, is the worst. It's essentially: we don't have a reason.

Yes, like car, a system will begin to show signs of wear. This can be alleviated by routine servicing. You know what they say about how a little preventative maintenance goes a long way. As an investment, routine servicing (i.e. refactoring and standardizing) will almost always be less costly than a rewrite.

However, we have to anticipate that a rewrite will eventually be necessary. Set dates and tentatively plan for it, but as the date draws nearer assess its actual necessity/worth and bump out the dates in favor of realizing other strategic goals.

Hold out for a good strategic reason like this:

In recent years we've lost the opportunity to win big accounts because we couldn't accommodate their needs in a timely or costly fashion. Our system will be rewritten using an extensible architecture that allows customizations to be plugged in (and not hardcoded as we currently do). This will dramatically decrease the time and cost of accommodating customers with special needs. We'll win more accounts and better meet the needs of our current customers.