A practical, vendor-neutral checklist for IT leaders, Power Platform admins and transformation teams planning a Power Platform or automation programme.

Most Power Platform programmes do not fail on the technology. They fail because the wrong things were assumed at the start - a licensing model picked before usage was understood, an on-premises dependency found halfway through, a security constraint that reshapes the whole design once the budget is already committed.

Readiness is the cheap insurance against all of that. Before you build or go to market to procure, you can assess where your organisation actually stands across the dimensions that decide whether a programme succeeds or stalls. This checklist walks through the eleven domains worth assessing in every engagement: what each one covers, and - more importantly - why each answer matters to cost, risk and architecture downstream.

How to use this checklist

Treat every domain as a question to answer honestly. A confident answer is reassurance; a “we’re not sure” is a finding in its own right - and far cheaper to surface now than after go-live. You do not need to be ready across all eleven to begin. You need to know where you stand.

The 11 domains at a glance

1. Business context & use cases

Everything starts here: the problems worth solving, the priority processes, and what success actually looks like. Vague problems produce vague specifications and the wrong tooling. And without an agreed success measure, there is no way to prove value or justify the spend. Transaction volumes matter too - they quietly drive your licensing model, your data-store choice, and whether unattended automation is even justified. The question that exposes most gaps: what does success look like, and how will you measure it?

2. Tenant & environment

This is the ground your platform stands on: who holds the Microsoft 365 and Power Platform admin roles, what environments already exist, and what data-loss prevention (DLP) policies are in force. Ungoverned default and personal developer environments are where shadow IT and data-loss gaps hide. Your Entra ID licensing tier (E3 versus E5) dictates which security controls you can use, and existing DLP designed around too late causes expensive rework. Ask first: who actually owns your environments and DLP today?

3. Data & integration

Power Platform is only as useful as the systems it connects to. Map your primary systems - ERP, CRM, HR, line-of-business apps - and, critically, which are on-premises. On-prem systems usually need an on-premises data gateway, one of the biggest hidden cost, timeline and architecture drivers in any programme. Databases such as SQL Server and Oracle force premium connector licensing, and existing SharePoint or Dataverse stores shape your whole data strategy. The question: which systems are on-premises, and have you accounted for a gateway?

4. Security & compliance

For most organisations this is where programmes slow down. Compliance obligations - ISO 27001, Cyber Essentials, GDPR - set non-negotiable controls, and Information Security sign-off is a hard dependency for DLP and security architecture. A slow connector-approval process can stall every premium use case, and mis-configured MFA or Conditional Access frequently breaks unattended automation. Engage InfoSec early; discovering their requirements late means rework. The question: has InfoSec been engaged, and how long does connector approval really take?

5. Infrastructure & network

The plumbing decides whether anything actually runs. Firewalls and proxies must permit outbound traffic to Microsoft endpoints, or connectors simply fail. Locked-down managed devices may block the Power Automate for desktop browser extension - a silent deployment blocker. Endpoint management such as Intune determines how desktop automation is rolled out at scale, and an existing Power BI gateway may be reusable, saving both cost and time. The question: can your managed devices install and reach what automation needs?

6. Governance & ways of working

Governance is the difference between adoption and sprawl. Decide up front who will own the Centre of Excellence (CoE) operationally - without that, the platform drifts into ungoverned app and flow sprawl. Governance-board cadence and change-approval maturity set the pace of every sign-off, and naming conventions are cheap to define now and costly to retrofit later. An existing architecture review board shortens approvals; its absence means governance must be built as part of the programme. The question: who will own the CoE once it exists?

7. Users & adoption

Technology adopted by no one delivers nothing. Estimate how many makers and consumers you expect in the first twelve months - that split drives your per-user versus per-flow economics directly. Current awareness levels dictate how much training is realistic and how quickly value arrives, while existing champions and an internal learning-and-development function dramatically reduce the cost of enablement. The question: how many makers and consumers in year one, and how Power-Platform-literate are they today?

8. Licensing & budget

Budget readiness is as important as technical readiness. You may already hold entitlements seeded in Microsoft 365 E3 or E5 that cover standard scenarios - and double-buying is a common, avoidable cost. Add-on licences carry procurement lead times that can delay environment provisioning, so a named budget owner and an approved budget are genuine delivery dependencies. If Copilot or AI Builder are on the roadmap, budget for them now, because they shape how extensible the architecture must be. The question: do you have an approved budget and a named owner for ongoing costs?

9. Power Automate licensing

Choosing the wrong licensing model is the single most common - and most expensive - Power Automate mistake. The maker-versus-consumer split drives per-user licence counts; shared, organisation-wide flows are often far cheaper on a per-flow plan; and premium connectors such as SQL, SAP and Oracle force premium licensing. Unattended automation needs an add-on per concurrent bot, and it is concurrency, not the number of processes, that drives the cost. The question: have you actually compared per-user, per-flow and RPA for your real usage?

10. Existing automation / RPA

If you already run automation, that history defines your starting backlog. Incumbent tools such as Blue Prism or UiPath set the scope and effort of any migration to Power Automate, and the number of processes in production sizes the timeline. The applications those processes touch - web, desktop, mainframe, SAP - determine what is feasible, and whether target machines are managed or unmanaged shapes deployment. Even VBA macros and scheduled scripts are quick-win migration candidates. The question: what are you migrating from, and how big is that backlog really?

11. Hosted machines & ALM/DevOps

The final domain covers the infrastructure that runs unattended automation and the discipline that ships it safely. Whether bots can run on Microsoft-hosted machines or must stay on-premises is a fundamental cost and compliance fork, sized by peak concurrency. On the delivery side, existing Azure DevOps shortens setup - but restrictions on creating service principals can block Power Platform Pipelines entirely. Source control, branching and release maturity decide how automated, and how safe, your deployments can be. The question: can you run bots in Microsoft’s cloud, and can you create service principals?

The gaps are the findings

Notice how few of these are really technical questions. Most are about ownership, process and assumption - which is exactly why they get skipped, and exactly why programmes stall. The value is not in scoring eleven green ticks. It is in surfacing the two or three honest “we don’t knows” before they become expensive surprises.

Why readiness matters more, not less, in the age of AI

Power Platform is moving quickly. Copilot and agentic AI are adding capability - and a new layer of consumption-based cost and governance risk - on top of everything above. That raises the stakes for readiness, not lowers them: the organisations that scale safely are the ones that understood where they stood before they committed budget. You can work through these eleven domains yourself, and you should. The questions are the straightforward part. Turning your answers into a costed, risk-assessed, sequenced roadmap is where the real value lies.

VE3’s free Power Platform Readiness Framework turns this checklist into a working tool: more than 100 questions across all eleven domains, each with a explanation of why it matters, plus worked examples of the risks and decisions a readiness assessment surfaces. Complete it at your own pace - and see exactly where your organisation stands before you commit a single pound. Get in touch to know more.