How long does application maintenance and support services take? A realistic timeline

Standing up application maintenance and support services takes six to ten weeks from signature to full ownership: two to three weeks of takeover discovery, two to four weeks of shadow on-call, then a dated handover of the rota and release approval. Emergency cover can start within days if it has to. After that the work is continuous rather than a project with an end date.

Below is the week-by-week shape, what can run in parallel, the four things that reliably add weeks, and how to compress the timeline when a runtime is going out of support next month and you do not have ten weeks.

The timeline at a glance

Read the gate column rather than the duration column. Each phase ends on evidence, not on a date, and a phase that ends on a date with its gate unmet simply moves the work into the next phase at a higher price. The commonest example is a handover that happens because the contract said month two, with runbooks still half-written, which turns hypercare into an unplanned second discovery.

Six weeks is achievable when documentation exists, credentials are already inventoried and one person on your side can answer questions the same day. Ten weeks is normal when the system is a decade old, the original developers have left and access has to be reconstructed from whoever still has a laptop with the right key on it.

What happens in each phase, and why it takes that long

Contracting and access: three to ten days

This phase is short in theory and the most common source of silent delay. Access is not one thing: repository, build system, cloud console, database, monitoring, domain registrar, certificate authority, app store accounts and third-party integration dashboards are all separate grants, often held by different people. Start the inventory on the day you start the contract conversation, not the day it is signed.

Takeover discovery: two to three weeks

Two weeks reads the system and writes it down; the third week exists when integrations are numerous or the data model is undocumented. Discovery is not open-ended research. It ends when an engineer who has never seen the application can handle a night-time severity-one incident from the runbook, and when a backup restore and a release rollback have both been performed rather than assumed. The full method is in our implementation guide to application maintenance and support services.

Shadow on-call: two to four weeks

The incoming team receives every alert and ticket and records what it would have done, while the existing owners retain responsibility. Two weeks is enough for a system with a steady incident pattern. Four weeks is right when the interesting failures are monthly, because a month-end batch failure you have never seen is a failure you cannot write a runbook for. If your application has a genuine seasonal shape, shadow through at least one cycle of it.

Handover and hypercare: one week, then two to four

Handover itself is a dated switch rather than a period. Hypercare is the elevated attention that follows: tighter monitoring, a daily check-in and a lower threshold for escalating to the outgoing team, tapering as the numbers settle. Skipping hypercare is the most common false economy in a transition.

What can run in parallel, and what cannot

• Tooling setup runs in parallel with discovery. Error tracking, dependency scanning and uptime monitoring can be configured while the system is being read.
• Backlog triage runs in parallel with shadow. The incoming team can sort and estimate the existing bug queue without owning it.
• Documentation runs in parallel with everything. Drafting from the code and correcting it as you learn beats writing it in one block at the end.
• Access provisioning cannot be parallelised away. Nothing meaningful starts until credentials exist, which is why it belongs in week one of the contract, not week one of delivery.
• Shadow cannot be shortened by adding people. It takes the calendar time it takes, because it is waiting for real incidents to occur.
• Handover cannot overlap. Two teams both believing they are on call is worse than either being on call alone.

What adds weeks

Four things, in the order they cost you most. Missing or disputed credentials, particularly domain and certificate ownership held by a former agency, can add two weeks on their own and occasionally require a legal conversation. An incumbent who is being replaced and knows it will answer questions slowly, so build the timeline assuming three-day turnarounds rather than same-day.

Regulated environments add their own clock. If access to production requires a background check, a signed data processing agreement or a change advisory board slot, those queues run on someone else's calendar and none of them can be accelerated by the engineering team. Ask early what approvals stand between a new engineer and production, because the answer is often two weeks that nobody put in the plan.

Thin or wrong documentation adds a week of discovery, though less than it used to: generating a first draft from the code and correcting it is far faster than starting blank, as set out in regenerating documentation for undocumented systems with AI. And a system with no test coverage adds time to every subsequent change rather than to the transition itself, which is the compounding cost argued in characterisation tests: the safety net for legacy code.

How to compress the timeline when you cannot wait

Sometimes the calendar is set by someone else. A runtime reaching end of support is the usual culprit, and those dates are published years ahead: Microsoft's product lifecycle policy states end-of-support dates for its products openly, and most major vendors do the same, so the deadline is knowable long before it is urgent.

When the deadline is real, split the work. Start incident cover and security patching immediately on a narrow scope, with a short written escalation path and no enhancement queue. Run discovery behind it over the following three weeks, and move the enhancement work in only once runbooks exist. You get protection in days and full ownership on the normal curve, which is far safer than compressing discovery and hoping.

When a fast transition is the wrong choice

Do not transition during your peak. A retailer moving support in October, a university moving it during admissions or a lender moving it at quarter end is buying risk to save a few weeks. The academic calendar was the binding constraint on the phasing in this university ERP programme, and it should usually win over a procurement date.

Do not compress shadow on a system with monthly or seasonal failure modes, because you will simply meet them for the first time in production while owning them. And do not start a full transition on an application you plan to decommission within two quarters: buy patching and incident cover, and put the saved weeks into the replacement.

Team, cost and what the clock costs

A transition needs an engineer who reads code, an engineer who knows the infrastructure and a delivery lead on the incoming side, plus one person on yours with production access and same-day authority. That single named person is the largest determinant of whether you land at six weeks or ten.

Steady state then runs on a published Care Plan: $1,000 or ₹68,000 a month for business-hours cover with an eight-hour response target, $2,500 or ₹1,60,000 for 24 x 5 with four hours, and $5,250 or ₹3,40,000 for 24 x 7 with a one-hour response, sixty engineering hours and a named engineer. Systems with models in production add $750 or ₹40,000. Inclusions are on the maintenance and support service page, and the figures are on the pricing page. Response targets are not resolution targets, a distinction taken apart in SLAs that mean something.

A timeline checklist

• Inventory every credential and access grant before the contract is signed
• Confirm who owns the domain, the certificates and the app store accounts
• Name one decision-maker on your side with same-day authority
• Check the calendar for peaks, audits and month-end batch cycles
• Decide shadow length by your failure cycle, not by the procurement date
• Fix the handover date in writing and tell both teams
• Plan two to four weeks of hypercare after the switch

Related reading

Application maintenance contracts: what should be in an AMC covers the clauses that set these dates, application maintenance and support services cost in 2026 covers the monthly figure, and questions to ask an application maintenance and support services vendor before you sign covers what to establish during selection. To get a transition plan dated against your own calendar, tell us what you run and when your peak is.

Six weeks is a good transition, ten weeks is a normal one, and the difference is almost always access and availability rather than engineering.