Uxdm Laravel Package

Product Decisions This Supports

• Build vs. buy for data import/onboarding. UXDM gives a ready-made pipeline abstraction (source migrators → field mappers → destination migrators → observers) so a "customer data import" epic can be scoped as integration work rather than a from-scratch ETL framework. It directly informs whether we staff a platform build or ship faster on an existing library.
• "Migrate from " as a roadmap differentiator. In most B2B SaaS, a one-click importer is a top-three switching-cost reducer. This package makes per-source importers (CSV, JSON, array, database/Eloquent, spreadsheet-style sources) cheap to add incrementally, which changes sequencing: we can ship one connector per quarter instead of one big "data platform" bet.
• Legacy cutover and internal migration projects. Supports decisions on how we move data during re-platforming, environment seeding, demo-data generation, and staging refreshes — work that otherwise lands as ad-hoc scripts with no ownership or repeatability.
• Where data movement lives in the architecture. Because it is an in-process PHP library rather than a hosted service, it anchors the decision to keep small migrations inside the application (jobs/CLI commands) rather than standing up a separate ETL service.
• Scope control on transformations. The mapper concept draws a clean line between "field-level transformation we own" and "transport we don't." That is a useful forcing function in roadmap debates about how much transformation logic belongs in product code vs. an external data tool.

When to Consider This Package

Consider it when:

• The codebase is PHP, ideally Laravel, and the team is already fluent in Composer, database access layers, and queued/CLI jobs.
• The work is batch or scheduled migration — onboarding imports, one-off cutovers, nightly syncs, seed/demo data — not real-time replication.
• Data volume is moderate: jobs that comfortably fit within PHP process memory and execution limits, or can be chunked by the caller.
• You need repeatable, testable migrations rather than one-off scripts, and you want progress/event hooks (observers) for job status and user-facing import feedback.
• You are willing to own the mapping logic and connector coverage yourself; the library provides the plumbing, not the business rules.

Look elsewhere when:

• Requirements are high-volume, streaming, or CDC (change data capture), or need guaranteed throughput/SLA — use a dedicated pipeline (Airbyte/Singer-style tooling, a managed ETL, or queue-backed custom workers).
• The transformation is mostly SQL pushdown, in which case plain SQL/stored procedures or database-native tooling will be simpler and faster.
• The stack is polyglot or not PHP — the value proposition collapses.
• Vendor support, SLAs, or security review artifacts are mandatory. At ~164 stars this is a single-maintainer-class dependency; plan for a bus-factor risk and a pin/audit policy.
• Legal/OSS policy rejects LGPL-3.0. It is generally workable when consumed as an unmodified dependency, but get counsel sign-off early rather than late — this is the most common blocker for a package like this.
• You need managed connectors and ongoing connector maintenance as a product commitment; that is a platform team's job, not a library's.

How to Pitch It (Stakeholders)

For executives: This is a small, free, open-source PHP component that provides the plumbing for moving data between systems. It lets us build customer-facing importers and internal migration tooling — the "switch to us without re-entering your data" capability — with meaningfully less engineering time than a bespoke build, and without a vendor contract. The main risks are that it is a low-community project and carries an LGPL license; we mitigate both by wrapping it behind our own interface, pinning the version, and limiting it to well-bounded batch jobs. Recommend a time-boxed pilot on one importer before committing it to the roadmap.

For engineering: It is a pipeline library, not a framework. You compose a Migration from source migrators (read), mappers (transform field-by-field), and destination migrators (write), with observers for progress and error visibility. That keeps transformation logic in our code and transport in the library, which makes imports unit-testable and connectors additive — adding a new source is a new migrator, not a refactor. It runs in-process, so it deploys with the app: no new infrastructure, no service to operate. Constraints to design around: batch-oriented, memory-bounded by the PHP process, so chunk large datasets at the call site; and we should define our own internal migration interface on top of it so an upstream abandonment or license review outcome is a swap, not a rewrite.