What to Do with a Business App Whose Maintenance Contract Has Ended — A Decision Table for Keeping It Running, Modifying It or Rebuilding It

The maintenance contract with the company that built your business app is about to end, or has already ended. The app runs every day, but nobody has decided who will fix the next bug or what to do if a Windows update breaks it. This article explains what a company without in-house developers should check in this situation and how to decide on a course of action.

There are three key points. Before the contract ends, obtain from the vendor everything another company would need to continue maintenance (the source code, the build environment, the design documents, the account information and confirmation of the rights). Next, find out the support dates of the OS, runtime, database and other components the app runs on. Then choose between keeping it running, modifying it and rebuilding it based on four points: whether it can be worked on, whether support for the runtime environment will continue, how much the business is changing, and how many more years you will use it.

The scope is business apps built by a vendor exclusively for your company (Windows apps and internal web systems). Off-the-shelf packages and SaaS are not covered here. How a contract is interpreted depends on the individual contract, so this article introduces the approach of IPA’s model contract and points out what to check in your own contract. When a legal judgment is required, consult a professional.

If you are taking over with neither the source code nor the specifications at hand, also read “When You Inherit a System With No Source Code and No Documentation.” For decisions about apps built with VB6 or Access, also read “Extending the Life of and Migrating VB6 / Access Business Apps.”

Work That Stops When the Maintenance Contract Ends

When a maintenance contract ends, the app itself does not stop right away. What stops is the work someone was doing to keep the app running. The following are examples of the work included in an operation and maintenance contract¹.

• Operational monitoring, backups and scheduled maintenance
• Answering questions about how to use the app
• Initial investigation and recovery when a failure occurs
• Fixing bugs
• Keeping up with OS and middleware updates
• Modifications such as adding features or changing screens

Once the contract ends, nobody takes on this work. The trouble comes when something happens. When reports stop printing after a Windows update, or a regulatory change requires a calculation to be changed, you have to start by finding someone who can fix it.

flowchart TB
        accTitle: Work that stops when the maintenance contract ends
        accDescr: Shows that after the maintenance contract ends the app keeps running, but nobody takes on monitoring, inquiries, failure response, bug fixes, keeping up with updates or modifications, so when something happens you start by finding someone who can fix it.
        END["Maintenance contract ends"] --> RUN["The app keeps running"]
        END --> STOP["Nobody takes on the maintenance work"]
        STOP --> S1["Monitoring, failure response, bug fixes"]
        STOP --> S2["Keeping up with updates, new features, modifications"]
        RUN -.-> EV["An update or regulatory change requires a change"]
        EV -.-> SEARCH["You start by finding someone to fix it"]

Figure 1: The app keeps running after the maintenance contract ends, but when a change is needed there is nobody to make it.

That makes the time before the contract ends important. While the relationship with the vendor continues, you can still obtain what you need and ask questions.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (6 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

What to Obtain from the Vendor Before the Contract Ends

Whether you ask another company to maintain the app, work on it yourself or rebuild it, you need information about the current app. What you obtain falls broadly into four groups.

flowchart TB
        accTitle: What to obtain from the vendor before the contract ends
        accDescr: Divides what to obtain from the vendor before the contract ends into four groups, source code and build environment, design documents and operating procedures, accounts and licenses, and confirmation of rights, and shows that all of them are needed for another company to continue maintenance.
        GET["What to obtain before the contract ends"] --> A["Source code and build environment"]
        GET --> B["Design documents and operating procedures"]
        GET --> C["Accounts and licenses"]
        GET --> D["Confirmation of rights"]
        A --> NEXT["Another company can continue maintenance"]
        B --> NEXT
        C --> NEXT
        D --> NEXT

Figure 2: What you obtain falls into four groups, and all of them are needed for another company to continue maintenance.

Source Code and Build Environment

The source code is not necessarily included in the deliverables. IPA’s “Information System Model Transaction and Contract” provides that the details of the items the vendor must create and deliver (the deliverables) are defined in the individual contract². The commentary on the same contract says that to have the source code and its accompanying documentation disclosed and handed over, you can either list the source code explicitly as a deliverable or make use of an escrow arrangement³. An escrow arrangement is a mechanism in which the source code and related materials are deposited with a third-party organization. In Japan, the Software Information Center (SOFTIC) serves as a software escrow agent⁴.

First open your contract and the individual contracts, and check whether the source code appears in the list of deliverables. If it does not, discuss with the vendor the conditions for obtaining it before the contract ends.

Source code alone is not enough to rebuild (build) the app. To produce the same executable, you also need the environment used for the build. The following table gives examples of what to check when you receive it.

Whether what is running now matches the source code you received is especially important. IPA’s commentary also gives examples in which only the source code was fixed during specification changes or failure response, while the documentation was not, so the documentation, the source code and the running system drifted apart³.

Design Documents, Operating Procedures and Accounts

In addition to the source code, obtain the following:

• Design documents, screen and report specifications, and database definitions
• Day-to-day operating procedures, failure response procedures and records of past failures
• Administrator accounts for servers and databases, and contracts and accounts for external services
• Domain names and server certificates, software license keys and the names they are registered under

If accounts and licenses are registered in the vendor’s name, you may not be able to renew or change them on your own after the contract ends. List whose name each one is in, and transfer to your company’s name whatever can be transferred.

Copyright and the Right to Modify

Even if you obtain the source code, whether you may modify it and keep using it depends on how copyright is handled. IPA’s model contract provides three options for the copyright in the deliverables².

• Option A: The vendor retains all of the copyright
• Option B: The vendor retains programs and other items that can be used for general purposes, and the rest is transferred to the user
• Option C: The vendor retains programs and other items that can be used for general purposes, and the rest is shared by the user and the vendor

In a contract that transfers copyright, unless the rights under Articles 27 and 28 of the Copyright Act, such as the right of adaptation, are “specifically mentioned as being included in the transfer,” they are presumed to remain with the party that made the transfer (Article 61(2) of the Copyright Act)⁵. This provision is why the clauses of IPA’s model contract state explicitly that these rights are included³. If your contract only says “copyright is transferred” and does not mention Articles 27 and 28, the rights involved in modification may still remain with the vendor.

Even if the copyright remains with the vendor, that does not mean you can do nothing. Article 47-3 of the Copyright Act allows the owner of a copy of a program to make reproductions to the extent necessary to run it on a computer themselves⁵. Options A and B of IPA’s model contract also provide that, for the parts whose copyright remains with the vendor, the user may make reproductions in accordance with this provision². IPA’s commentary also says that the Copyright Act allows the owner of a copy to make certain modifications, reproductions and adaptations of a program, and that a user who does not hold the copyright can outsource maintenance and operation to another company³. However, how far modifications can go depends on the individual contract, so check your contract and consult a professional if in doubt.

flowchart TB
        accTitle: How copyright is handled and what to check
        accDescr: Shows looking at the copyright clause of the contract, checking whether the rights under Articles 27 and 28 are also stated explicitly if copyright has been transferred to the user, and, if it remains with the vendor, checking the scope allowed to the owner of a copy and whether maintenance can be outsourced to another company.
        C["Copyright clause in the contract"] --> Q{"Who holds the copyright?"}
        Q -->|"Transferred to the user"| M["Are the Article 27 and 28 rights also stated?"]
        Q -->|"Retained by the vendor"| V["Check the scope allowed to the copy owner"]
        Q -->|"Shared"| S["Check the terms of sharing"]
        M -.-> L["If not stated, the rights may remain"]
        V -.-> O["Outsourcing maintenance is considered possible"]

Figure 3: What to check depends on who holds the copyright.

Support Dates for the OS, Runtime and Database

A business app runs on an OS, a runtime such as .NET Framework, a database, reporting and communication middleware, and commercial components. This article calls all of these together the runtime environment. Even after the maintenance contract ends, the support end dates of the runtime environment’s components keep approaching.

Microsoft products covered by the Fixed Lifecycle Policy get at least five years of Mainstream Support, and for some products Extended Support follows⁶. During Extended Support, security updates are provided, but requests for design changes and new features are not accepted. After Extended Support ends, security updates are provided only through the Extended Security Update (ESU) program⁶.

ESU is a paid, last-resort option for customers who need to keep running older products after support ends. It is described as a temporary bridge until you move to a newer supported environment, not something for long-term use, and it includes security updates for up to three years after the end of Extended Support⁷. It does not extend the product’s lifecycle either⁷.

flowchart TB
        accTitle: The stages of the Fixed Lifecycle Policy
        accDescr: Shows a product under the Fixed Lifecycle Policy moving through Mainstream Support, Extended Support and end of support, with security updates continuing during Extended Support and, after the end of support, security updates for up to three years available only through the ESU program.
        MS["Mainstream Support (5+ years)"] --> ES["Extended Support"]
        ES --> EOS["End of support"]
        MS -.-> M1["Security updates and feature requests"]
        ES -.-> E1["Security updates continue"]
        EOS -.-> X1["Up to 3 years of security updates via ESU"]

Figure 4: Once Extended Support ends, security updates are available only through ESU.

You can look up support dates by product and version on Microsoft Lifecycle’s search page⁸. Look up other companies’ products in each maker’s published information. Put the results in a list like the following.

Making this list shows how many more years the app can run as is, and which components need attention first.

A Decision Table for Keeping It Running, Modifying It or Rebuilding It

Organize what you have found so far into four questions.

1. Can it be worked on? Do you have the source code, the build environment and the right to modify it, and is there someone (including another company) who can fix it?
2. Will support for the runtime environment continue? When does support for the OS, runtime and other components end?
3. How many business change requests are there? How often will regulatory or business changes require screens or calculations to change?
4. How many more years will you use it? Has the end of use been decided?

From these four, choose a course of action as follows.

flowchart TB
        accTitle: How to choose between keeping it running, modifying it and rebuilding it
        accDescr: Shows asking in turn whether it can be worked on, whether support for the runtime environment continues, and whether there are many change requests and long use ahead, and making keeping it running the candidate if it cannot be worked on and change requests are few, modifying it if it can be worked on and the runtime environment is within support, and rebuilding it if the runtime environment's support has ended, change requests are many and it will be used for a long time.
        Q1{"Can it be worked on?"}
        Q1 -->|"No"| Q3{"Many change requests and long use?"}
        Q1 -->|"Yes"| Q2{"Will runtime support continue?"}
        Q2 -->|"Continues / can be moved"| KAI["Modify it"]
        Q2 -->|"Ends"| Q3
        Q3 -->|"No"| EN["Keep it running"]
        Q3 -->|"Yes"| TSU["Rebuild it"]

Figure 5: Choose a course of action based on whether it can be worked on, whether runtime support continues, and the change requests and period of use.

The table and the figure are rough guides. Even within one app, combinations are possible, such as rebuilding only the reporting part and keeping the rest running. Deciding feature by feature lets you start smaller than rebuilding everything at once.

How to Proceed When Keeping It Running

Keeping it running means continuing to use the current app with as few changes as possible. Because you do not work on it, costs stay down, but once the runtime environment’s support ends you remain unable to receive security updates. For that reason, choose to keep it running only after deciding “until when.”

1. Preserve the running environment as a whole. Copy the executables, configuration files, database and installers, and confirm that you can restore from the backups.
2. List the end-of-support dates of the runtime environment’s components and use the earliest one as a rough deadline for keeping it running. If the OS is covered by ESU, check whether you can use that period as a bridge⁷.
3. Decide when use will end and what will replace it. While the app is being kept running, prepare for the next course of action (modifying or rebuilding).

flowchart TB
        accTitle: How to proceed when keeping it running
        accDescr: Shows that when keeping it running, you preserve the running environment as a whole, set a deadline from the runtime environment's end-of-support dates, check whether ESU can be used as a bridge if it applies, and decide when use will end and what comes next.
        A["Preserve the running environment as a whole"] --> B["Set a deadline from runtime support end dates"]
        B --> C{"Is the OS covered by ESU?"}
        C -->|"Covered"| D["Check whether ESU can serve as a bridge"]
        C -->|"Not covered"| E["Prepare the next course before the deadline"]
        D --> E
        E --> F["Decide when use ends and the replacement"]

Figure 6: Choose to keep it running with a deadline, and prepare the next course of action in the meantime.

How to Proceed When Modifying It

Modifying it means working on the source code you received and continuing to use the app. If you have no in-house developers, you will be looking for a new maintenance provider (another company).

The first thing to check is whether you can produce, from the source code and build environment you received, the same executable as the one running now. If you cannot, what you received is incomplete or differs from what is running. If you start modifying features before this check, differences unrelated to what you fixed may slip in.

When working on an app that has no tests, one approach is to first create tests that record its current behavior before the fix (characterization tests) and then make the change. How to proceed is explained in “Safely Modifying a Legacy Business App That Has No Tests.”

In a contract with a new maintenance provider, the basic split is a quasi-mandate contract for ongoing work such as monitoring and answering inquiries, and a contract for work, estimated individually, for modifications whose content can be defined¹. How to define the scope of maintenance is covered in “How Should You Structure a Custom Software Development or Operations & Maintenance Contract?.” So as not to repeat what happened under the previous maintenance contract, decide at the outset in the new contract that the source code is included in the deliverables and how copyright is handled.

flowchart TB
        accTitle: How to proceed when modifying it
        accDescr: Shows that when modifying it, you check whether you can produce the same executable from the source code and build environment you received, identify what is missing or different if you cannot, record the current behavior with characterization tests before changing it if you can, and decide on deliverables and copyright with the new maintenance provider at the outset.
        A["Build from what you received"] --> B{"Did you produce the same executable?"}
        B -->|"No"| C["Identify what is missing or different"]
        C --> A
        B -->|"Yes"| D["Record current behavior with characterization tests"]
        D --> E["Make the change"]
        A -.-> F["Agree deliverables and copyright with the new provider"]

Figure 7: Start modifying only after confirming that you can produce the same executable.

How to Proceed When Rebuilding It

Rebuilding it means rebuilding the business app on a new runtime environment. In exchange for being usable for a long time, it carries the risk of missing specifications the current app has.

The commentary on IPA’s model contract says that when rebuilding a system that has been operated and maintained for many years, there are often problems such as nobody understanding the specifications, documentation being scattered, and the running system not matching the design documents and source code. It therefore says that before entering requirements definition, the current system must be investigated to clarify its specifications, and the risks of rebuilding and the countermeasures must be shared and agreed between the user and the vendor³.

The same commentary also calls attention to the requirement to “carry over the current system as is.” The user expects the running current system to be reproduced exactly, while the vendor relies on what is written in the design documents and source code, so the two sides’ ideas of “the current system” can differ³. Simply asking for it to be “the same as now” is not enough; write down what is to stay the same and agree on it.

There is also a way to move to the new system feature by feature instead of replacing everything at once. The Strangler Fig pattern is a migration approach in which a component that routes requests (a facade) is placed in front of the existing system, features are moved to the new system bit by bit, and the old system is finally shut down⁹. However, it is described as unsuitable when requests to the old system cannot be intercepted along the way, or when neither the source code nor the database can be modified⁹.

flowchart TB
        accTitle: How to proceed when rebuilding it
        accDescr: Shows that when rebuilding, you investigate the current system and write down its specifications, agree between the user and the vendor on what carrying over the current system means, choose whether to replace it all at once or move feature by feature, and, when moving feature by feature, route requests through a facade and finally shut down the old system.
        A["Investigate the current system"] --> B["Write down the specifications"]
        B --> C["Agree on what carrying over the current system means"]
        C --> D{"Can it be replaced all at once?"}
        D -->|"Yes"| E["Switch over to the new system"]
        D -->|"Difficult"| F["Move feature by feature to the new system"]
        F --> G["Finally shut down the old system"]

Figure 8: Rebuilding starts with investigating the current system and agreeing on what “carry over the current system as is” means.

What You Can Do Before and After the Contract Ends

Finally, here is what you can do at each stage. Before the contract ends, you can ask the vendor to hand things over and answer questions. After it ends, you have to rely on what you have and on what can be learned from the running system.

flowchart TB
        accTitle: What you can do before and after the contract ends
        accDescr: Shows that before the contract ends you obtain materials and confirmation of rights from the vendor, look up the runtime environment's support dates and decide on candidate courses of action, and after the contract ends you proceed based on what you received and an investigation of the running system.
        subgraph before ["Before the contract ends"]
            B1["Obtain source code, materials, accounts"] --> B2["Check how copyright is handled"]
            B2 --> B3["Look up runtime support dates"]
            B3 --> B4["Decide candidate courses of action"]
        end
        subgraph after ["After the contract ends"]
            A1["Check what you received"] --> A2["Investigate the running system"]
            A2 --> A3["Keep running, modify or rebuild"]
        end
        B4 --> A1

Figure 9: Before the contract ends, obtain things from the vendor; after it ends, rely on what you have and on the running system.

If the contract has already ended and you have neither the source code nor the materials, start by preserving the running environment and reconstructing the specifications from its behavior. The steps are explained in “When You Inherit a System With No Source Code and No Documentation.”

Related Articles

• When You Inherit a System With No Source Code and No Documentation
• Extending the Life of and Migrating VB6 / Access Business Apps
• How Should You Structure a Custom Software Development or Operations & Maintenance Contract?
• Safely Modifying a Legacy Business App That Has No Tests
• Practical Options After Windows 10 End of Support

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These are topic pages close to this theme. Starting from the article, you can go on to related services and other articles.

Services Connected to This Topic

This article leads to the following service pages. Start from the entry point closest to your situation.

Frequently Asked Questions

Questions commonly asked at the time of consultation about the topic of this article.

Can we keep using a business app after its maintenance contract has ended?

The app does not necessarily stop when the maintenance contract ends. However, there is no longer anyone to investigate failures, fix bugs or keep up with OS and middleware updates. If you are going to keep using it, obtain the source code, the build environment, the design documents and the account information before the contract ends, so that another company can take over maintenance.

Shouldn't the source code be included in the deliverables?

Not necessarily. Under IPA's model contract, the deliverables are defined in the individual contract, and to have the source code disclosed and handed over you either list the source code explicitly as a deliverable or use an escrow arrangement. First check your contract and the list of deliverables in the individual contract.

If the vendor still holds the copyright, can we ask another company to maintain the app?

The commentary on IPA's model contract says that the Copyright Act allows the owner of a copy of a program to make certain reproductions and adaptations, and that a user who does not hold the copyright can still outsource maintenance and operation to another company. How far you can go, however, depends on the clauses of the individual contract, so check your contract and consult a professional if necessary.

How should we choose between keeping the app running, modifying it and rebuilding it?

Decide on four points: whether you or another company can work on it (whether you have the source code, the build environment and the rights), whether support for the OS and runtime will continue, how many business change requests there are, and how many more years you will use it. If nobody can work on it, change requests are few and the end of use is in sight, keep it running; if it can be worked on and the runtime environment is within support, modify it; if support for the runtime environment has ended and there are many change requests, rebuilding becomes a candidate.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and bug investigation, with particular strength in projects where existing assets remain and in investigating failures whose cause is hard to see.