Old internal systems: Should we fix them or build new ones?

Current situation faced by the company

Companies with internal systems that have been in use for over 10 years often find themselves in the same situation. The system is still operational. There are no major outages. However, a small request takes two weeks, and there is only one person in the company who can handle that request.

The reason this situation is dangerous is that problems worsen gradually. A system that suddenly stops will immediately have a budget allocated. However, a system that slows down little by little and requires more effort each year transitions to "we managed to get by this year too." As the years pass, three issues will arise simultaneously.

First, the person in charge who knows the system leaves the company. Unwritten business rules disappear with them. Second, security support for the underlying technology ends. Languages or database versions that lose support will not receive patches even if vulnerabilities are discovered. Third, new requirements cannot be added. Requests for mobile responsiveness, external service integration, and data analysis are continually rejected with "That’s not possible with the current system."

When three challenges arise simultaneously, the only option left is a complete overhaul. A complete overhaul is the most expensive and riskiest choice.

Five signs that you should consider a replacement

If three or more of the following items apply, it is time to start considering replacement.

1. Change costs are asymmetric. Adding one item to the screen takes several days. If the development time for minor and major user requests is not significantly different, the structure is already unable to accommodate changes.

2. There is only one maintenance personnel. A system that can only be handled by a specific individual poses a business risk when that person takes leave or resigns. This is not a personnel issue but a structural issue.

3. Support for the underlying technology has ended. Check the official end-of-support dates for the language runtime, frameworks, and databases you are using. If the date has already passed, a security incident is only a matter of time.

4. Unable to extract data. If the person in charge has to write queries themselves to extract the numbers needed for management decisions, or manually sum them up by opening multiple screens, then the system is locking the data away.

5. Workarounds are increasing. If the business is increasingly managing areas with Excel instead of the system, it means that the system does not reflect actual operations. These workaround tasks are not recorded anywhere, so problems are not visible just by looking at the system.

Calculate maintenance costs

The reason discussions about replacement do not progress is usually, 'Why spend money when it still works?' To answer this question, it is essential to demonstrate that there are costs associated with maintenance as well. Sum the following four items.

The first three items are costs that have already been incurred but are not accounted for in any budget. The fourth item is a cost that has not yet occurred but accumulates probabilistically.

Below is a hypothetical example to illustrate the calculation method, and actual values will vary based on each company's conditions. If there are 30 change requests annually, with an average waiting time of 10 days and an opportunity cost of 150,000 won per day due to delays, the delay cost alone is 45 million won per year. If two departments spend 5 hours a week on Excel dual management, an additional 13 million won will be added based on a total labor cost of 25,000 won per hour.

If the total is 58 million won per year, that amounts to 170 million won over three years. This is the first point where we can compare costs with replacement expenses. Maintenance is not free; it’s an expense that doesn’t come with a bill.

Reasons why a complete overhaul is risky

Once the decision to replace is made, the first method that comes to mind is a complete rebuild. Stop the old system, create the new one, and switch over all at once one day. It's intuitive but carries three risks.

The benefits are 0 until the project completion date. In a 12-month overhaul, the organization pays costs for 11 months without experiencing any improvements. If the business environment changes during this period, the project will face pressure to halt.

Requirements become outdated midway. The requirements outlined at the start differ from the needs of the business a year later. If these differences are reflected, the schedule will slip; if not, an outdated system will be completed.

Risks are concentrated at the point of transition. Since all functionalities are changed at once, if issues arise on the day of transition, there are few ways to revert. And problems almost always occur because there are always exception rules in the existing system that no one remembers.

An alternative of phased transition

Instead of a complete overhaul, there is a method to transition functionality while keeping the existing system intact. The order is as follows.

Step 1 — Drawing Boundaries

Break down the current system into functional units. Divide it by business units such as orders, inventory, settlements, and HR, but draw the line based on who owns the data. If multiple units are directly modifying the same table, that point will later become the biggest obstacle.

When drawing boundaries, follow the data flow rather than the organizational chart. Even if departments are separated, if they are working on the same data together, they form a single entity. Conversely, if data is completely separated within a department, it can be divided.

Step 2 — Separate from reading

The safest first task is the query function. Functions that only read data, like dashboards, statistics, and reports, can be created in the new system without affecting the existing one. Even if it fails, the existing screens remain intact, making it easy to revert, and the business will immediately feel the improvements.

There is an additional side effect gained at this stage. While creating the query functions, issues with existing data will become apparent. Duplicate clients, broken date formats, and empty code values will be discovered here. It is important to identify these issues before migrating the write functions.

Step 3 — Migrating Write Functionality

Once verification through queries is complete, migrate the input and modification functions. During this time, both systems will handle the same data, so designate one side as the original. Allowing both sides to be modified simultaneously will lead to discrepancies, which will take more time to resolve than the original issue.

It is safer to address features that are used infrequently and have a narrow impact first in the migration order. However, if you start by migrating features that no one uses, validation will not occur, so features that are actually used but can afford to be paused for a day are the best starting point.

Step 4 — Reduce the existing system

Remove the migrated functions from the existing system remove. If left in place, some business staff will continue to use the old screens, ultimately leading to the permanent maintenance of two systems. Delaying this step is the most common reason for the failure of phased migrations.

If removal is difficult, at least block access and change it to read-only. Also, set a date for when it will be completely removed. Plans for cleanup without a date will not be executed.

Which option will you choose?

A complete rebuild is not always wrong. If the scope is small, business rules are documented, and a few hours of downtime are acceptable, it can be faster and cheaper to change everything at once. The criterion for judgment is not the age of the system but where the rules are recorded.

Real Issues in Data Migration

The reasons for schedule delays are usually not due to feature development but rather data. The old system has accumulated the following states.

• The same client is registered multiple times with different notations.
• The formats for dates, phone numbers, and business registration numbers vary by period.
• There are empty rows for mandatory fields
• There is data referencing a code value that no longer exists
• Rows that are marked for deletion but are actually mixed with remaining ones

These issues will definitely delay the schedule if discovered in earlier stages. Investigate in advance before starting, and first define the scope to organize and what to discard. Trying to perfectly organize all past data can lead to endless delays. It is often more realistic to organize only the last few years of data and keep the rest in read-only storage.

An opportunity to redesign security and access permissions

Replacement is also a rare opportunity to streamline the security system. Old systems often have loose permission separations, and most personnel can access more data than necessary. During the transition, clarify the following items together.

Minimize access permissions. Separate the data so that only the necessary information is visible based on roles. If you simply transfer the permission structure from the existing system, you will also carry over old issues.

Identify the storage location and retention period of personal data. Organize what personal data is stored where and when it will be destroyed. If moving to the cloud, also verify the country where the data will be stored.

Preserve processing history. Keep a record of who changed what and when. Many old systems lack this record, making it difficult to trace the cause when issues arise.

How to persuade management

Replacement budgets typically do not pass based on technical logic. Explanations like "the structure is outdated" or "technical support has ended" do not convey urgency to decision-makers. Present it in the following three ways.

The amount currently being leaked. This is the total of the delay, workaround, and error costs calculated earlier. The key point is that costs are already being incurred even without replacement.

Things that have not been done. Over the past year, create a list of rejected requests citing "the current system cannot handle it". If there are items linked to revenue or customer churn, place them at the top. Opportunity loss is a stronger justification than maintenance costs.

In the worst case. Estimate the time and cost for recovery when the sole responsible person resigns or an incident occurs with a component that has reached end-of-support. Even if the probability is low, a large scale can influence decision-making.

After presenting the three points, request approval for only the first step of phased migration. Asking for the entire budget at once will prolong the review period, and in the meantime, the situation may worsen.

How will you schedule and allocate resources?

The schedule is often misaligned during phased migrations. Please reflect on the three aspects in advance.

Include the time of the business staff in the schedule. The most lacking resource in previous projects was not developers but business staff who understand the business rules. They participate while performing their main duties, so if the available time is not agreed upon in advance, schedules will slip at every validation stage.

Include the parallel operation period in your calculations. After migrating functionality, both systems will need to operate together for a while. During this period, the operational burden actually increases. If this is not reflected in the schedule and budget, there will be a shortage of personnel in the final stage.

Set aside a separate period for data cleanup. The consistency issues discussed later can proceed in parallel with development, but separate time and personnel are required. If buried within the development schedule, it will inevitably be delayed.

Things to check when working with external vendors

It is often difficult to carry out the migration with only internal personnel. If considering external vendors, verify the following before contracting.

Does the deliverable include documentation? If you only receive the code, the same problems will recur years later. Business rule definitions, data structure descriptions, and operational procedures must be included in the deliverables.

Is there a defined handover process since the previous version? After the implementation, internal staff should be able to operate it. Specify the handover period and training scope in the contract.

Can we contract in stages? Contracting everything at once makes it difficult to change direction midway. A structure where you execute the first stage and then decide on the next is safer for both parties.

Is the authority over our data clear? If real data is used during the development process, document what data moves where and how it is disposed of after completion.

Preparation before commencement

Regardless of the approach, ensure you have the following three things secured before starting.

Document the current business rules. Rules that exist only in code will inevitably be omitted during the migration process. Even if it is not a perfect specification, please document the exception handling and approval conditions in writing.

Data integrity check. Investigate the current status based on the items outlined earlier and define the scope of organization.

Plan for rollback. At each stage, determine "how to roll back if a problem occurs." Irreversible steps indicate that the stage is too large and should be broken down further.

Organization

The costs of an outdated system manifest not as failures but as delays and dependencies. Therefore, they are recognized late.

• Check five aspects: change costs, concentration of personnel, end of technical support, data accessibility, and workaround tasks.
• Calculate maintenance costs based on four factors: delays, workarounds, errors, and risks, and convert them into comparable figures against replacement costs.
• If rules remain only in the code, a complete overhaul is risky.
• Start by migrating the query functions, and ensure that the migrated functions are removed from the existing system.
• Data integrity should be investigated before starting, and the scope should be defined in advance.
• Redesign access permissions and personal data retention policies during this opportunity.

More important than whether to replace is not to delay judgment. If three out of five signals apply, it is more cost-effective to start the review this year than to undertake a complete overhaul next year.