Uxdm Laravel Package

Product Decisions This Supports

• Build vs. buy for data plumbing. UXDM is a small, focused PHP library that handles the boring 80% of a data migration: read from a source, map/transform fields, write to a destination, show progress. The decision it most directly informs is whether we hand-roll that loop again (as we likely have on prior migrations) or adopt a 164-star library and spend our engineering budget on business rules instead of fgetcsv and PDOStatement boilerplate.
• Roadmap sizing for migration/decommission epics. Any epic of the shape "get customers off Legacy System X" or "consolidate 3 tenant schemas" can be scoped with UXDM as the transport layer. That changes the estimate from "multi-sprint bespoke ETL project" to "connector work + mapping rules + reconciliation." Directly reduces the cost line on a replatforming business case.
• Feature: self-serve or assisted data import. The source/destination adapters (CSV, JSON, PDO databases, arrays, Eloquent models) map cleanly onto a "bring your data with you" onboarding feature — import a customer's CSV export into our schema during implementation. Also useful for data portability/export and offboarding obligations (GDPR access & erasure, contract termination exports), where a repeatable, testable pipeline beats a one-off script.
• Prioritizing internal tooling vs. product work. Because this is a library, not a platform, "adopt UXDM" is a cheap spike (days, not weeks) that can de-risk a larger buy decision. The output of that spike is a real input to "do we buy Fivetran/Airbyte or build?"
• Risk register inputs. It surfaces two decisions PMs own, not engineers: (a) our policy on LGPL-3.0 dependencies in a commercial product, and (b) our tolerance for single-maintainer, low-star dependencies in the critical path. Both need an explicit answer before it lands in a customer-facing flow.
• Environment and QA strategy. Using a declarative migration object makes seeded/staging environments and large-scale test fixtures a configuration exercise rather than a script library — supports decisions about test-data strategy and release confidence for migration cutovers.

When to Consider This Package

Adopt (or spike) when:

• The stack is PHP 8+ / Laravel and the work runs as an Artisan command, queued job, or scheduled task — not in a request cycle.
• The migration is batch and offline: nightly syncs, one-time cutovers, backfills, onboarding imports. Not real-time, not CDC.
• Source and destination are among the supported shapes: PDO/MySQL/Postgres, CSV, JSON, PHP arrays, Eloquent models.
• Volumes are in the thousands-to-low-millions of rows and a runtime of minutes to hours is acceptable.
• The team is small, there's no budget or appetite for an ETL platform, and speed to a working pipeline matters more than enterprise features.
• You can absorb a coarse-grained failure model — re-run the migration, or track progress per item — rather than requiring transactional, all-or-nothing cutover.
• Legal is comfortable with LGPL-3.0. Practically this is usually fine for a hosted SaaS (no distribution of the library), but it needs a written answer if we ship on-prem or distribute a packaged PHP app, and it needs a policy on contributing modifications back.

Look elsewhere when:

• Non-technical users need to do the mapping. UXDM's mapping is code. If the requirement is "ops can remap columns without a deploy," we need a UI on top — that's a build, or an Airbyte/Fivetran-class tool.
• Volumes or latency exceed a PHP CLI loop. Millions of rows with tight windows, parallel workers, or incremental CDC belong in a database-native or dedicated ETL tool. Push transformations into SQL/dbt rather than PHP.
• Complex transformation logic — joins, aggregations, deduplication at scale — is better expressed in SQL, dbt, or a warehouse.
• Vendor support, SLAs, or indemnity are required. 164 stars and a single primary maintainer is a real bus-factor risk. Acceptable for internal tooling and one-off migrations; a harder sell inside a paid customer onboarding flow with uptime commitments.
• The stack isn't PHP, or the team would rather not add a dependency for something they can write in 200 lines.
• You need observability out of the box — dashboards, retry state, alerting, audit trails per record. UXDM gives you a migration runner; the operational wrapper is ours to build.

How to Pitch It (Stakeholders)

To executives (2 sentences): UXDM is a free, open-source PHP library that handles the mechanics of moving data between systems — CSV to database, database to database, legacy to new — so our engineers write the business rules instead of re-writing file parsing and batch inserts on every migration. It's low-cost and low-commitment, and it has the potential to cut weeks off a replatforming or customer-onboarding epic; the trade-off is a small open-source dependency that we should wrap behind our own interface and validate in a short spike before committing it to a customer-facing path.

To engineering: It's a source → migrators → destination pipeline with adapters you'd otherwise write yourself (PDO, CSV, JSON, array, Eloquent) and a pluggable mapping/skip/callback layer. Fit it as an internal library behind our own DataImporter interface, keep it out of request handlers, add golden-file fixtures and reconciliation checks, pin the version, and monitor releases. Call out the LGPL-3.0 license explicitly and get a one-line legal ruling recorded.

What it does not solve (say this out loud): no UI, no scheduling, no per-record audit trail, no distributed execution, no vendor support. Those are ours, and that scope gap is precisely what the spike should size.

Recommendation: Timebox a one-to-two-week spike against a real legacy dataset, measured on throughput, reconciliation accuracy, and wrapper effort. If it clears, adopt for internal migrations and onboarding tooling; keep the customer-facing, high-volume, and real-time paths on a platform tool.