Benzina Laravel Package

Product Decisions This Supports

• Upgrade vs. rebuild vs. stay put. For anyone operating a Goteo v3 instance, this package is the concrete artifact that makes "migrate to v4" a real option rather than a theoretical one. It bounds the cost of upgrading and gives you something to scope against; without it, the honest comparison is "rebuild" or "freeze on v3."
• Build vs. inherit. It answers the question "do we write our own ETL or start from something?" — and the answer is "start from this, then own it." Forking is the decision, not adopting.
• Roadmap sequencing and dependency mapping. Migration tooling is a hard gate on any v4 feature that touches legacy data. It belongs on the critical path with an owner and a date, not filed as cleanup work at the end of the release.
• Data fidelity requirements. The tool's field mapping is effectively a product decision about which history users keep — contribution records, co-financing relationships, campaign audit trails, user identity. Reviewing the mapping is how you discover what you're silently dropping.
• Cutover strategy. Chunked, re-runnable migration implies a big-bang-with-retries model. Whether that's acceptable (downtime window, dual-run, rollback) is a PM call this package forces early.
• Reference architecture for other legacy moves. The chunk-read → transform → idempotent-write pattern is reusable for analytics backfills, CRM syncs, and billing history when you don't want to stand up a full ETL stack.

When to Consider This Package

Consider it when:

• You run a Goteo v3 instance and v4 is the target — this is plausibly the only published migration path, and ignoring it means writing the mapping from scratch.
• You want a worked example of a Laravel-domain schema migration between two non-trivial models to read and borrow from, not to depend on.
• You're pricing the Goteo ecosystem and need to know whether upgrade cost is bounded or open-ended.
• You're estimating migration effort — the package's scope is a reasonable proxy for the work involved.

Look elsewhere when:

• You are not on Goteo. There is no generality here; this is a single-project utility, not a library.
• You need maintained, versioned, documented tooling with support guarantees. Zero stars, zero dependents, and a zero composite score mean no ecosystem safety net and no upstream fix pipeline. Fork, pin a commit, add tests, and own it — or don't use it.
• Your target schema diverges from canonical Goteo v4. The mapping is hard-coded to that domain and will fight you elsewhere.
• You want a general-purpose pipeline. Airbyte, Singer, dbt, or plain queued Laravel jobs will serve better and be maintainable by people who aren't Goteo specialists.
• Procurement or security review requires release history and provenance you can audit.

How to Pitch It (Stakeholders)

Executives: This is an internal upgrade utility for the Goteo crowdfunding platform, not a product component — no customer-facing surface, no commercial upside. Its only strategic value is that it converts "rewrite the platform" into "migrate the platform," which is materially cheaper and lower-risk. It is unmaintained externally (no stars, no dependents), so the recommendation is to fork and own it rather than treat it as a dependency. The decision on the table is upgrade cost and data continuity, nothing else.

Engineering: A Laravel migration tool mapping Goteo v3 entities into the v4 schema. Maturity signals are weak across the board — treat it as a reference implementation, not a dependency. Use it to bound the mapping scope and borrow the chunked/idempotent-write pattern; then fork it, pin it, add test coverage, and assign an owner. Before committing to a cutover plan, validate field coverage against our actual v3 data — the mapping determines what history we keep. Assume no upstream fixes and design a rollback or dual-run path accordingly.