Legacy Sync Laravel Package

Product Decisions This Supports

• Legacy migration strategy (strangler-fig / phased cutover): the package enables dual-write between the legacy database and the new Laravel application, so product can ship new features on the modern stack before the legacy system is retired, instead of a big-bang rewrite.
• Build vs. buy for sync plumbing: v0.3.0's deleteRecord() closes the last obvious gap in CRUD parity (create/update were already implicit; reads come from the app DB). This shifts the decision from "do we build a bespoke sync layer?" toward "do we adopt a thin package and spend our engineering budget on product surface?" — the remaining custom work is policy, not plumbing.
• Data lifecycle policy is now a product decision, not just a technical one: delete propagation means a delete in one system can cascade into the other. Product must decide which side is system-of-record for deletion, whether deletes are soft or hard, and whether deletion requires approval. These are roadmap-level decisions (e.g., "can a support agent delete a customer and have it vanish from the legacy ERP?").
• Roadmap gating for cutover: each release that rounds out CRUD narrows the window in which the legacy system must stay writable. deleteRecord() is a milestone that unblocks retiring legacy admin screens that currently own deletion — a concrete roadmap checkpoint.
• Use cases now supported end-to-end: customer/account record offboarding, GDPR/CCPA erasure requests spanning both systems, cleaning up records created in error during dual-write, and test-data teardown in staging environments.
• Risk posture for the release: deletion is the first genuinely destructive capability in this package, and it lands at 0.x. Treat this as a feature-complete-but-unsafe-by-default release: plan a rollout with soft deletes, audit logging, and a dry-run/confirmation path before enabling it in production.

When to Consider This Package

Consider adoption when:

• You are mid-migration from a legacy database (ERP, AS/400, bespoke PHP app) to Laravel and need a bounded dual-write window, not permanent replication.
• Your sync volume is low-to-moderate (thousands of records/day, not thousands/second) and eventual consistency of seconds-to-minutes is acceptable to the business.
• You can own the failure modes: reconciliation jobs, dead-letter handling, and an idempotency story are yours to build — the package moves records, it does not guarantee distributed transactions.
• You are comfortable pinning to an exact 0.x version and budgeting for breaking changes; the public API is still moving (this release added a method, not a breaking change, but the 0.x signal stands).
• The legacy schema is stable enough to map and you can express the record shape as a small, well-understood transformation.

Look elsewhere when:

• You need real-time or high-volume replication — use CDC tooling (Debezium, AWS DMS, native logical replication) rather than an application-level package.
• You need strict cross-database transactional guarantees or exactly-once semantics; dual-write is inherently best-effort and this package does not change that.
• Compliance requires immutable, auditable change history across both systems — you would need to layer your own audit trail, at which point the buy-vs-build case weakens.
• The team has no appetite for destructive operations: without soft-delete and reconciliation discipline, deleteRecord() is a liability rather than a feature.
• Volume, schema churn, or a single-maintainer dependency is a blocker for your risk model — in which case build a narrow, in-house sync command you fully control.

Recommended adoption pattern for v0.3.0: adopt, pin the version, enable create/update first, and hold deleteRecord() behind a feature flag until soft-delete plus an audit log are in place. Add a reconciliation report to the definition of done for the migration epic.

How to Pitch It (Stakeholders)

For executives (one paragraph): We're evaluating a small open-source Laravel package that lets our new application and the legacy system stay in sync while we migrate. The newest release adds the ability to delete records from the other database, which means the package now covers the full create/update/delete lifecycle. Practically, that lets us start retiring legacy admin screens and running erasure requests across both systems, shortening the migration and reducing the period where we pay to run two systems in parallel. The cost is low and the lock-in is minimal — it's a thin layer we can replace with our own code or a replication tool later. The trade-off is that deletion is destructive, so we'd introduce it behind a flag with audit logging rather than switching it on. Recommendation: pilot on one low-risk entity next quarter, with a go/no-go based on reconciliation accuracy.

For engineering (short brief): clarkewing/legacy-sync v0.3.0 adds deleteRecord() (PR #2), completing CRUD for the secondary/legacy connection. It's a 0.x package with a single maintainer — pin the exact version and read the source before relying on it. Integration plan: wire create/update first, verify against a reconciliation query, then gate deleteRecord() behind a config flag, require soft deletes on the app side, log every propagated deletion with actor and timestamp, and provide a manual replay/restore path. Do not treat dual-write as a consistency guarantee — assume it can fail and design idempotent consumers accordingly. Estimate: small integration effort, most of the work is in the safety and reconciliation layer around it.