Does stable mean we can extend?

No. Stability describes unplanned failures, which is how often a system breaks when nobody touches it. Extensibility describes planned change, which is whether the system can absorb a new obligation at a predictable cost. A system can score perfectly on the first and fail the second, and the most common version of that is a system that is stable because nobody changes it. Ask when a non-trivial change last shipped and how long it took. If the answer is that teams route around the system now, the extend-versus-replace decision has already been made informally.

Our SharePoint Server 2019 farm has not had an outage in two years. Is that enough to extend it?

Uptime is not the constraint here, and the reason has nothing to do with the farm. Microsoft's Ending Support in 2026 lifecycle page, read 2026-08-22, lists SharePoint Server 2019 as reaching End of Support on July 14, 2026, alongside SharePoint Server 2016, SharePoint Designer 2013, InfoPath 2013, Project Server 2016 and 2019, and SQL Server 2016. The SharePoint Server 2019 product lifecycle page shows the same boundary as an Extended End Date of 7/15/2026 6:59:59 AM Pacific under the Fixed Lifecycle Policy. Microsoft states that after end of support there are no new security updates, non-security updates, assisted support options, or online technical content updates. A clean two-year run does not change that. What you can still extend is the business capability, onto a supported platform: the SharePoint Server Subscription Edition lifecycle page, read the same day, shows a Retirement Date of In Support under the Modern Lifecycle Policy.

Is extending always cheaper than replacing?

In a regulated estate that assumption is usually wrong. An extension inherits the compliance obligation of whatever it attaches to. Regulated-industry SharePoint modernization carries roughly 25 to 35 percent cost overhead versus commercial work for equivalent scope, driven by control mappings, audit-trail discipline, and zero-downtime cutover patterns, and that overhead applies to the extension as well. The test is whether the extended system can produce the artifacts for the new scope at the same grain and cadence without new manual effort. If the answer needs a person and a spreadsheet, price that manual step per reporting cycle and add it to the extension estimate, because a build estimate prices construction rather than the annual proof cycle that follows it.

Do we have to decide for the whole estate at once?

Trying to is the most common way this decision goes wrong. The four tests sort each system into one of four dispositions: extend, wrap, rebuild, or retire. A typical estate contains all four at the same time, so a single estate-wide verdict forces the wrong disposition onto some systems by construction. Produce a list, assign a disposition per row, and record the finding that justifies it next to the row. Retire is the disposition most often missed, because nobody is usually assigned to look for processes that are duplicated elsewhere or no longer used.

How long does an assessment like this take?

It depends on scope, and it should be scoped as an assessment rather than a project. The i3 Risk and Roadmap Assessment ROI variant is a one-week structured engagement that produces a business case anchored on the specific environment, the specific compliance frameworks, and the specific executive-cycle timing. Enterprise SharePoint strategy assessment engagements typically run four to six weeks elapsed time with two to three i3solutions consultants. Where the outcome is a modernization program rather than a decision memo, Microsoft modernization consulting engagements with i3solutions run from approximately four months for single-workstream scope to approximately twelve months for multi-workstream scope with significant compliance evidence requirements.

Are Our Current Systems Stable Enough to Extend, or Too Fragmented to Build On?

Q: How do we measure fragmentation instead of arguing about it?

Count two things: how many platforms hold a piece of the workflow, and how many integration points join them, including the undocumented ones such as scheduled exports, service accounts with mailbox rules, and the spreadsheet someone downloads every Monday. Those counts are how the work is actually scoped. At i3solutions, a Stabilization Protocol engagement (Phase 1 dependency mapping plus Phase 2 risk-sequenced triage) typically costs between $85,000 and $175,000 for enterprises running four to six Microsoft platforms with 40 to 120 integration touchpoints. Also count systems of record holding the same entity, identity and authentication paths, and custom surface area, which is routinely larger than the owning team believes.

By Justin Bowen, Sr. Vice President, Delivery Services, i3solutions

The question almost never arrives as a question. It arrives as a sentence someone says in a budget meeting with a rising tone at the end: “the systems are basically fine, we can just extend them, right?” Everyone in the room has a different answer and none of them has evidence, because “fine” is not a measurement. The platform owner means it has not gone down. The application lead means the last three change requests each took a quarter. The compliance lead means the audit evidence is assembled by hand every year and nobody wants to say so out loud. All three are describing the same estate and all three are correct.

Are the current systems stable enough to extend, or are they too fragmented and constrained?

Stable and extensible are different properties, and most estates have the first without the second. Answer the question per system rather than per estate, against four tests: supportability, dependency count, evidence obligation, and change-failure behavior. One of the four is a matter of public record rather than judgment. Microsoft’s Ending Support in 2026 lifecycle page, read 2026-08-22, lists SharePoint Server 2016, SharePoint Server 2019, SharePoint Designer 2013, InfoPath 2013, Project Server 2016, Project Server 2019, SQL Server 2016, and Dynamics GP 2016 as reaching End of Support on July 14, 2026. A system past end of support fails the extend test no matter how stable it feels, because “no new security updates” is not a property you can engineer around. The other three tests are judgment calls, and they resolve into a disposition per system: extend, wrap, rebuild, or retire. A single verdict for the whole estate is almost always the wrong shape of answer.

The estate is stable because nobody changes it, which is not the same as extensible

Stability is a statement about unplanned failures: how often the thing breaks when nobody touches it. Extensibility is a statement about planned change: whether the system can absorb a new obligation at a cost you can predict before you commit to it. They are measured differently, they fail differently, and one does not imply the other.

The uncomfortable case is the system that is stable because nobody changes it. Its uptime is excellent. Its change-failure rate is unknown, because there have been no changes. Every person who understood its integration surface has left. It is not stable in any sense that helps you decide whether to build the next three years of business capability on top of it. It is dormant, which reads as stable right up until the moment you ask it to do something new.

Two questions separate the cases in about five minutes, and they are worth asking before any assessment is scoped:

When did a non-trivial change last ship to this system, and how long did it take? If the honest answer is “we route around it now,” the estate has already made the extend-versus-replace decision informally, and the only open question is whether it gets made on purpose.
Who could change it next week if they had to? A named person who is still employed is a different answer from a vendor relationship that lapsed and a folder of documentation nobody has opened.

Test one: the platform went out of support five weeks ago and nobody in the room mentioned it

This test is first because it is the only one that does not require an assessment to answer. It is published, dated, and binary, and for a large number of Microsoft-centered estates it resolved five weeks ago.

Microsoft’s Ending Support in 2026 page, read 2026-08-22, groups the following under “Products reaching End of Support” with an End of Support date of July 14, 2026: Dynamics GP 2016, Dynamics GP 2016 R2, InfoPath 2013, Project Server 2016, Project Server 2019, SharePoint Designer 2013, SharePoint Server 2016, SharePoint Server 2019, SQL Server 2014 Extended Security Updates Year 2, and SQL Server 2016. The page states that “Upon retirement or end of support, there will be no new security updates, non-security updates, free or paid assisted support options or online technical content updates.”

The individual product pages express the same boundary as a Pacific-time timestamp. The SharePoint Server 2016 lifecycle page lists a Mainstream End Date of 7/14/2021 and an Extended End Date of 7/15/2026 6:59:59 AM, and the SharePoint Server 2019 page lists a Mainstream End Date of 1/10/2024 and the same Extended End Date. Both follow the Fixed Lifecycle Policy. It is one boundary described two ways, not two dates.

A few more from the same Ending Support in 2026 page land inside the same planning horizon and are easy to miss because they sit in different parts of the estate: Dynamics CRM 2016 reached End of Support on January 13, 2026; Dynamics NAV 2016 and Dynamics C5 2016 on April 14, 2026; Office LTSC 2021, Windows 10 2016 LTSB, and Windows Server 2012 and 2012 R2 Extended Security Update Year 3 on October 13, 2026.

How to read this test. Past end of support, “extend” is not a decision you get to make about the platform. It is still a decision you can make about the capability: the business process the old system carries can be extended onto a supported platform. The SharePoint Server Subscription Edition lifecycle page, read the same day, lists it under the Modern Lifecycle Policy with a Retirement Date of “In Support,” which is what a live extend target looks like. Confusing the platform question with the capability question is what produces the false choice in the room: nobody wants to replace a business process that works, and nobody has to.

Test two: two people argue about whether the estate is fragmented and neither has a number

That argument runs on adjectives because nobody has produced the count, and it can be settled in a week. Fragmentation has two countable dimensions: how many platforms hold a piece of the workflow, and how many integration points join them.

Those counts are how modernization work is actually scoped. At i3solutions, a Stabilization Protocol engagement (Phase 1 dependency mapping plus Phase 2 risk-sequenced triage) typically costs between $85,000 and $175,000 for enterprises running four to six Microsoft platforms with 40 to 120 integration touchpoints. That band is worth reading as a diagnostic rather than a price: an estate in it is one where the dependency map does not exist yet and has to be built before any extend-versus-replace call can be defended.

The sequence matters more than the number. Typical Stage 1 dependency mapping for a mid-market regulated enterprise runs between $45,000 and $120,000 depending on estate size; the Stage 2 risk-sequenced migration plan runs between $30,000 and $75,000 depending on the phases involved; the Stage 3 stabilization plan and the migration execution that follows scope to the engagement. Dependency mapping is Stage 1 because a disposition assigned before the map exists is a guess wearing a schedule.

What to count, concretely:

Integration touchpoints, including the undocumented ones. Scheduled exports, a service account with a mailbox rule, a spreadsheet somebody downloads every Monday. These are load-bearing and they are almost never on the architecture diagram.
Systems of record holding the same entity. If three systems each believe they own the customer, extending any one of them extends the disagreement.
Authentication and identity paths. Fragmentation in identity is the kind that turns a six-week extension into a six-month one, because it is discovered late and cannot be worked around.
Custom surface area. Custom code, custom columns, custom workflows. This is routinely larger than the owning team believes, and it is the specific thing that makes a platform upgrade stop being an upgrade.

Test three: the assessor asks for proof at a grain the architecture was never built to produce

That is the moment the third test gets failed, and it arrives long after the extension shipped. In a regulated estate, an extension inherits the compliance obligation of whatever it attaches to, and the obligation stays invisible until somebody asks for the artifacts. It is also where the assumption that extending is automatically the cheaper option comes apart. Regulated-industry SharePoint modernization carries roughly 25 to 35 percent cost overhead versus commercial work for equivalent scope, driven by control mappings, audit-trail discipline, and zero-downtime cutover patterns. That overhead does not stop at the boundary of the original system; it applies to whatever you attach.

An extension bolted onto a system whose audit trail is assembled by hand does not inherit a cheap obligation. It inherits an expensive one, and it usually makes the manual work larger, because there is now more scope to document on the same annual cycle.

The practical question: if you extend this system, can it produce the artifacts for the new scope at the same grain, on the same cadence, without new manual effort? If the answer needs a person and a spreadsheet, price that manual step per reporting cycle and add it to the extension estimate. Build estimates price construction. They do not price the annual proof cycle that follows it.

Test four: one team adds a field and four other teams have to be in the room

The last test is behavioral and it is the one that most reliably separates an estate that can be extended from one that cannot. It is not “does it break.” It is “what happens downstream when we deliberately change one thing.”

Three signals are worth collecting before any decision, and all three are available from history rather than from a new study:

Blast radius per change. When one system changed last, how many other teams had to be involved? An estate where a field addition requires four teams is fragmented in the way that matters, whatever the platform count says.
Time from request to production. Not the build estimate, the elapsed time. The gap between the two is the coordination cost of the current architecture, and extension multiplies it.
Rollback confidence. If the team cannot describe how a change gets reversed, the estate is not stable, it is untested. Nobody has attempted the thing that would reveal the instability.

Four test results, four dispositions, one row per system

The four tests do not average into a verdict. They sort each system into one of four dispositions, and a healthy estate typically contains all four at once.

Disposition	The reading that produces it	What it commits you to
Extend	In support, low dependency count, evidence produced automatically, small blast radius	Build the next capability here. Re-run the supportability test annually, because it is the one that changes without warning.
Wrap	In support or near end of support, but high dependency count or an unclear change history	Put a governed interface in front of it and build against the interface. Buys time and reduces blast radius without funding a rebuild.
Rebuild	Past end of support, or the evidence obligation cannot be met without manual effort, and the process still matters to the business	Move the capability to a supported platform. The process survives, the platform does not.
Retire	Past end of support and the process is duplicated elsewhere or no longer used	The cheapest outcome in the set, and the one most often missed because nobody is assigned to look for it.

The reason the estate-wide answer fails is visible in the table: “extend” and “rebuild” are frequently both correct in the same estate, for different systems, in the same quarter. A single verdict forces one of them onto systems where it does not fit, and the cost of that mistake is paid quietly over the following two years.

What it costs to answer this properly, and how long it takes

Running the four tests is an assessment, not a project, and it should be scoped as one. For reference points from i3solutions engagements:

The i3 Risk and Roadmap Assessment ROI variant is a one-week structured engagement that produces a business case anchored on the specific environment, the specific compliance frameworks, and the specific executive-cycle timing.
Enterprise SharePoint strategy assessment engagements typically run four to six weeks elapsed time with two to three i3solutions consultants.
Microsoft modernization consulting engagements with i3solutions run from approximately four months for single-workstream scope to approximately twelve months for multi-workstream scope with significant compliance evidence requirements.

i3solutions delivers through its Expert Delivery Model, a four-phase methodology (discovery, architecture, build, and knowledge transfer) with explicit exit criteria and delivery assurance at every handoff. For this decision, the phase that matters is the first one, and the exit criterion is specific: a named disposition for every system in scope, with the finding that produced it.

Two ways this decision goes wrong, and what each one costs

An estate-wide verdict. “The systems are fine” and “the systems need replacing” are both estate-wide claims, and an estate is not a system. The correction is mechanical: produce a list, assign a disposition per row, and require the finding that justifies it next to it.

Extending onto a platform that is out of support. This is the expensive one, because it looks like the cheap option on the day it is chosen. The build lands, it works, and the platform underneath it has no security updates. The extension then has to be redone inside the migration that was deferred, and it is paid for twice.

The upside of getting the disposition right is not theoretical. One IT systems analysis for a federal housing agency identified about $1.5 million in savings and led to processing roughly 35 percent faster by finding the real constraints. One modernization retired about $500K a year. One integration for a commercial real-estate operator processed work about 40% faster while retaining roughly 90% of historical data, and that speed repeats on every cycle, not once. When i3 rebuilt a spreadsheet-bound estimating process into a web application, it removed version-control errors across hundreds of estimates and cut approval cycles from five days to one. In each case the value came from correctly identifying which systems were the constraint, not from replacing everything.

The room has been split on this for two quarters and nobody has written the list down

When a leadership team cannot agree on whether an estate can be extended, the disagreement is almost never about the estate. It is that four different tests are being run informally, in four heads, and no one has produced the row-by-row list that would let the tests be compared. An outside read is useful mainly because it forces that list to exist, with a named disposition and the finding behind it, before anyone commits budget to a direction.

That list is also the thing you take into a committee. Most of the people who have to approve an extend-versus-replace decision were not in the technical conversations, and what convinces them is not a recommendation. It is a supportability date they can check against a vendor page, a touchpoint count, and a clear statement of which systems the decision does not apply to. A short scoping conversation before committing budget is usually enough to establish whether the list can be produced in a week or needs a full dependency map first.

You will get a straight answer either way, including the answer that the current estate is in support, is not meaningfully fragmented, and should be extended rather than touched. That is a common finding and a legitimate outcome of the work.

Talk to a senior architect