Who owns the app once it's finished?
That’s the question we ask at the final meeting, and it’s the one we should be asking at the very first one. A business application isn’t something you buy and take home: it’s a collection of elements—an interface, rules, data, access rights, hosting—whose ownership can be divided among several parties without anyone ever having written a single line of code.
The day you decide to switch providers, cut costs, or simply figure out what you have, you discover the actual breakdown. It’s usually an unpleasant surprise—and one that can be avoided.
Six Questions to Ask Before Signing
Where is your data stored, and under whose name? The only correct answer is: in a subscription that belongs to you, opened in your name, and paid for by you. A subscription in the provider’s name—even if it’s well-maintained—turns your data into an asset hosted by a third party, and terminating the contract is like moving your data to a new location.
Can you retrieve them without him? Not “is it covered by the contract”— do you know how to do it? A complete export, in a readable format, tested at least once before the project ends. A contractual guarantee that’s never been invoked isn’t worth much when the relationship sours.
Who has administrative access? You need at least one person at your company who can access everything, including revoking the service provider’s access. This isn’t a matter of mistrust; it’s the same rule that applies to keys to your office.
Who owns what has been written? For custom development, it’s clear-cut: the code produced for you belongs to you, and you receive a copy of it. For an application built on the platform, the question is different but still relevant: Is the application in your environment, exportable, or in a space that belongs to the service provider?
What is documented? Not a user manual, but what a successor will need: the business rules that were applied, the connected systems, the technical identifiers used, and what was intentionally left out. An undocumented application is one in which the service provider is, in effect, a co-owner.
How long does it take for someone else to take over? Ask the person you're consulting this question exactly as it is. An honest answer—a few days, a few weeks—indicates a job well done. Hesitation suggests the opposite.
Note: None of these questions are meant to imply mistrust. A reputable service provider will be happy to answer them, because they accurately describe how they already work.
Why it's easier on your own base
When the tool is built within the Microsoft environment you’re already paying for, many of these issues resolve themselves. The data is in your tenant. The accounts are your accounts. Permissions are based on the directory you manage. The service provider works within your environment, with access that you grant and revoke.
This isn't a product-related issue; it's an ownership issue. On a third-party platform hosted by an integrator, each of these points becomes a clause to be negotiated—and the clauses can only be verified when they are actually put to use.
The signal that should serve as a warning
A service provider who offers to host the service “at their own location to keep things simple” doesn’t necessarily have bad intentions: it’s often actually simpler that way when you’re just starting out. But you end up paying for that simplicity all at once later on, and you always pay for it at the worst possible moment—a business dispute, a change in personnel, or a resumption of operations.
The right way to respond isn't "I don't trust you." It's: "What happens if you stop doing business?" It's a legitimate question—one that any serious company has already considered.
What to Do
- Open the subscription in your name before the project begins.
- Designate one person at your organization who will have administrative access.
- Make sure the contract specifies who owns the work produced and that you receive a copy.
- Insist on a full export test before final payment for the project.
- Request the handover documentation as part of the deliverables, not as an optional item.
- Raise the issue of the recovery period once a year.
Lambert Consulting works within your environment, using your access credentials, and documents what it builds so you can make changes to it. This is also what makes it possible to confidently choose between an application at Power Apps and development at Azure: in both cases, the resulting product remains on your servers.
Microsoft Sources
What an article Can't Know
An article describes what applies to everyone. What varies from one organization to another is the inventory: which applications, which accounts, and which pieces of equipment are actually involved in your organization. The inventory determines the scope of the effort, and it cannot be summarized on a single page.
You'll be speaking directly with the engineers who will be doing the work, not with a middleman. We'll respond within 24 business hours.
Check what is still true
Announced dates are sometimes postponed, products are renamed, and conditions change. The blog tracks these topics over time: when a rule changes, a new post announces it.
Search for a topic in the blogIn the same issue
Three articles on the same topic. The blog has 149 articles, all of which are freely accessible.