Choosing an ETL Tool When Your Data Team Is One Person

Most ETL advice is written for teams that do not exist in asset-heavy organisations. It assumes a data platform group, a staging environment, and a couple of engineers who own the pipelines. What I usually find instead is one analyst who also writes the reports, an IT team that owns the servers but not the data domain, and a CMMS or ERP that nobody fully understands. If that is your world, the right tool is not the most capable one. It is the one that will still be running, and still be fixable, after the person who built it moves on.

The reality you are buying for

Start by being honest about the constraints, because they matter far more than any feature list.

• One analyst. They know the business, SQL, and probably Power BI. They are not a software engineer and should not have to become one to keep the lights on.
• No data-engineering team. Nobody is on call for pipelines. Nobody writes unit tests for a transformation.
• IT owns the plumbing, not the meaning. They can give you a server, a service account, and a firewall rule. They cannot tell you why a work-order status changed.
• Handover risk is the real risk. The analyst leaves, goes on leave, or gets pulled onto a project, and the reports must survive.

Everything below is scored against that reality, not against a data-platform team you do not have. If you have not yet mapped how your source systems talk to each other, my enterprise system integrations guide is the better place to start before you shop for a tool.

The five categories worth considering

Ignore individual product names for a moment. There are really five categories, and each behaves differently under a one-person team.

1. Cloud-native orchestration. Managed pipeline services such as Azure Data Factory or the pipeline features inside Microsoft Fabric. Strong connectors, visual authoring, cloud billing. Powerful, but the failure experience can be opaque if nobody configured alerting properly.
2. Low-code iPaaS. Integration platforms that link systems with drag-and-drop connectors and prebuilt templates. Fast to start, friendly to non-engineers, priced per connection or task.
3. SQL-first transformation tooling. Tools like dbt where the logic lives in version-controlled SQL. Your analyst already speaks SQL, so the skills gap is small, but you still need something to move raw data in and to schedule the runs.
4. Scheduled scripts. A Python or PowerShell job on a server, triggered by cron or Task Scheduler. Cheapest to start, highest handover risk, because it is only as documented as the author chose to be.
5. The CMMS vendor's own export scheduler. Many CMMS and EAM platforms can email or drop a scheduled CSV. Zero new licence, zero new skill, but limited transformation and usually weak alerting.

Category comparison

Scored for a one-analyst estate. Higher is better on skills fit and alerting; lower is better on cost and handover risk, so read the columns, not a single total.

A worked selection: 5 sources, 3 reports

Take a realistic estate: a CMMS, an ERP, a plant historian, an HR feed for headcount, and a spreadsheet of cost centres. Five sources feeding three reports, one analyst maintaining them. Score each category from 1 (poor) to 5 (good) against weighted criteria. I weight for survivability, not power, because that is what actually costs money later.

Weights:

• Handover risk (can a non-author keep it alive): 30%
• Error alerting (do you learn about a failure before the business does): 25%
• Connector coverage (does it actually reach your five sources): 20%
• Skills fit (can your analyst run it today): 15%
• Licence cost (lower is better): 10%

The maths is simple: multiply each score by its weight and sum. For low-code iPaaS that is (4 × 0.30) + (4 × 0.25) + (4 × 0.20) + (4 × 0.15) + (2 × 0.10) = 1.20 + 1.00 + 0.80 + 0.60 + 0.20 = 3.80. The top three land within a rounding error of each other, which is the real finding. There is no single winner here. The decision comes down to a tiebreaker, and the tiebreaker is not on this table.

The tiebreaker: what happens at 06:00

Reports run overnight. The one that matters fails at 06:00, before anyone is awake. That single moment decides whether you chose well, and it hinges on three questions.

• Does someone get alerted, with a usable message? Not "pipeline 4 failed" but "the CMMS extract returned zero rows, downstream report X is stale." An alert nobody can act on is noise.
• Can the job be safely re-run? If re-running duplicates rows or double-counts costs, your analyst will be afraid to touch it, and fear is how stale data reaches a director's dashboard.
• Can a non-author diagnose it? The person who built the pipeline is on leave. Can the next person open it, read what broke, and fix it without reverse-engineering someone's cleverness?

This is why scheduled scripts score so badly on survivability despite being free, and why the CMMS export scheduler, cheap and simple as it is, loses on alerting: a silent failed export looks identical to a quiet day with no changes. If you are already living in Power BI, the same discipline applies to the last mile too, which I cover in connecting Business Central to Power BI and, for the maintenance side, connecting Power BI to IBM Maximo.

The connector that exists on a marketing page

One vendor-neutral warning that applies to every category on the table. A connector listed on a marketing page is not the same as a connector that works with your version of your CMMS. I have seen "supports Maximo" turn out to mean a specific cloud edition with a REST API your on-premise install does not expose. I have seen historian connectors that assume a driver your site never licensed.

Before you sign anything, prove the connection against your exact source: your CMMS version, your ERP release, your historian's actual interface, with a real service account and your real firewall rules in the way. A one-hour proof-of-connection during evaluation saves a month of "why does the connector not see our custom fields" after purchase. If the vendor cannot demonstrate it against your instance, treat the connector as not existing.

Where I usually land

For a one-analyst, asset-heavy estate I most often recommend a pairing rather than a single tool: a managed loader or a low-code iPaaS to move data in reliably and alert on failure, with SQL-first transformation for the logic your analyst already understands and can hand over. Cloud-native orchestration earns its place when the connector breadth is genuinely needed and someone will invest the hour to configure alerting properly. Scheduled scripts stay in the toolbox for genuine one-offs, never for anything a report depends on. The CMMS export scheduler is a fine stopgap and a poor foundation.

But notice that the categories, not the brands, drove every decision above. That is deliberate.

A note on independence and naming

I do not resell any of these tools and I am not paid by their vendors. My interest is a pipeline that still runs when I am not in the room, because that is what I get called back to fix when someone else's does not.

One caution on names. Microsoft in particular renames and re-packages its data products often, and licensing shifts with it, so treat any specific product name or price here as a starting point and verify it against the vendor's current documentation before you commit. As a rule I check the canonical source rather than a comparison blog, including my own.

Two canonical references worth bookmarking:

• Azure Data Factory documentation
• dbt (SQL-first transformation)

Conclusion

With a one-person data team, capability is table stakes and survivability is the whole game. Weight your criteria toward handover risk and alerting, run the 06:00 test on every finalist, and prove the connectors against your actual systems before you buy. Do that, and it barely matters which of the sensible middle categories you land on. Skip it, and the cheapest tool becomes the most expensive one you own.