A pattern we see across customer tenants: a wave of Extend apps gets built in the first eighteen months of capability, and then a quieter year follows where two or three of them go silent. Usage drops. Nobody quite remembers who owns it. A Workday release tweaks something underneath and nobody notices until a user complains. The app does not break loudly. It fades.
The good news is that the reasons are knowable, and the fix is mostly a matter of agreeing how the app will live before you ship it.
Pick a support model before you build
Three options. In-house means your team handles everything: fixes, enhancements, regression testing against each Workday release. It works if you have a centre of excellence or are actively building Extend capability. It does not work if your team is one HRIS analyst with a full inbox. Extend talent is scarce. Losing a key person can take a year of institutional knowledge with them.
External means a partner, usually the one who built the app, holds the support contract. They do the testing, the small enhancements, and the watch for issues. You pay for the expertise, but you remain dependent on a third party for quick fixes. Good for teams without internal capability. Less good if you want to build long-term independence.
Hybrid is what most mature customers settle into. Your team handles day-to-day issues, simple configuration changes, and user support. A partner handles release testing, complex changes, and serves as a fallback when something genuinely odd happens. This model gives your team room to grow capability without making them the single point of failure.
Budget the line teams always forget
Most business cases for Extend show the build cost cleanly. The recurring cost line is where they get vague. A realistic ongoing budget includes the Extend license itself, support labour (internal or contracted), an enhancement allowance of roughly two to four weeks per year per active app, training for the people who maintain it, and a 10 to 15 percent contingency. Skip any of these and the variance shows up eighteen months later as a "why is this so expensive now" conversation.
For an app of moderate complexity, a useful planning number is around 0.1 to 0.3 full-time equivalent per year of ongoing support, depending on user volume and how often you want to enhance. That is not a rule, it is a starting point that has held up across the apps we have shipped.
What actually changes with Workday releases
Workday ships two major releases a year. The platform is designed so Extend apps remain stable across them, and in practice the API versioning works. Apps rarely break outright. What does happen is that small UI behaviours shift, a delivered field gets renamed, or a new feature in the platform overlaps with something your app does.
The discipline is dull but mandatory. Test every active Extend app in the preview tenant before each release lands in production. Maintain a short regression checklist per app, covering the critical user paths and any integration points. Read the release notes for the modules your app touches. The work is repetitive, and that is exactly why it prevents the silent decay that turns a useful app into a forgotten one.
Track usage, not just uptime
Uptime is rarely the problem with Extend. The app is up. The question is whether anyone is using it. Usage data is the early warning that something is going wrong: adoption is lagging, a UI change confused people, a competing process emerged, or the original problem went away.
Build logging into the app from day one. Track logins, completions, drop-offs by step, and the most common error paths. Look at the data quarterly. If usage is declining for an app that should be busy, investigate before users find a workaround.
“Extend apps rarely die from a broken release. They die from nobody noticing that nobody is using them anymore.”
Name the owner before the project closes
This is the cheapest improvement you can make to your Extend operating model and the one most often skipped. Before the project closes, name one internal person as the owner of the app. Not a team. One name. They do not have to write code. They have to know the app exists, know what it does, and be the person tickets get routed to.
Without this, the app becomes a tenant artefact that nobody fully understands. The person who built it moves on. The HRIS lead changes. Six months later, a user asks a question and nobody knows where to start. With a named owner, that path is short. Without one, the app is on a clock you have not seen yet.
Consider a Centre of Excellence, but only when the volume justifies it
Once you have three or four Extend apps in production, a lightweight centre of excellence starts to earn its keep. The COE sets standards for naming, security, and testing. It prioritises the request backlog. It owns the roadmap. It runs the regression cycle for releases. Importantly, it does not have to be internal. A specialist partner can play the COE role for organisations that do not want to staff one themselves.
Below three apps, the overhead of a formal COE outweighs the benefit. A shared spreadsheet, clear ownership, and an honest support contract usually cover it.
Train, but do not overestimate what training delivers
Workday offers an Extend for Non-Developers course (two days) and a full developer track for those who will actually build. The non-developer course is genuinely useful for HRIS analysts who will support apps without writing code. The developer track is necessary if you are staffing a real build capability.
What training does not deliver is competence on real apps. Just like core Workday, Extend skill grows on the job. The most reliable way to build capability is to deliver the first one or two apps alongside a partner who is committed to knowledge transfer, not just delivery. That is two months of paired work that outperforms four months of classroom learning. Make sure knowledge transfer is in the statement of work, not a "knowledge sharing session" at the end of the project.
What post-launch stewardship actually looks like
Stewardship on an Extend app is unglamorous and specific. Each live app has a single named human who knows what it does and where tickets land. The support model is written down, even if it fits on a page. Someone in the team has the preview tenant open in the weeks before each release and walks a short regression script. Usage data is read quarterly, and there is permission in the room to say an app is no longer earning its keep, with a documented path to turn it off. None of this is dramatic, and that is the point: the apps that stay useful in year three are the ones where this quiet rhythm became routine, not the ones where governance lived in slide decks.
