Move legacy systems without breaking the workflow the business depends on.
I plan and execute production migrations where historical data, staff workflow, uptime, and auditability matter more than a clean-room rebuild fantasy.
For FileMaker, Access, spreadsheet, SaaS, or fragile cloud systems that have become business-critical and can't be replaced naively. The operation has to keep running through the migration. Production cutover has to be safe enough to ship without a 3 AM rollback.
Who this engagement is for
Who this is for
- Companies sitting on a 10+ year FileMaker, Access, or spreadsheet-glued operational stack staff genuinely depend on, where modernization needs to preserve workflow without losing it.
- Teams running on a SaaS platform that has become a constraint (vendor lock-in, missing features, plugin economics, lost data ownership) and need an exit plan that does not interrupt revenue.
- Owners whose business runs on a fragile cloud setup that grew organically (someone clicked things in the AWS console for years) and now needs repeatable IaC + sovereign architecture before scale or diligence.
- Companies with regulated workflows (financial, energy, healthcare, audit-heavy) where the migration must produce auditable evidence at every step.
- Buyers who have been burned by a previous migration project that overran, broke production, or shipped a system that staff couldn't operate.
- Engineering teams that need an outside senior engineer to own the cutover risk and the architecture decisions before the migration starts.
Who this is NOT for
- Lift-and-shift cloud migrations where the goal is simply to move existing infrastructure between hosting providers.
- Teams that want a migration but cannot commit to operating the new system after launch.
- Buyers who will not invest in production-clone rehearsals or staff workflow research; the migration math doesn't work without that discipline.
- Greenfield builds with no legacy system to migrate. Custom Application Development is the right engagement for those.
Where this engagement starts
The problem
Migration projects fail in predictable ways. The team underestimated the legacy system's edge cases. The cutover plan didn't account for what staff actually do every Friday. The rollback path was theoretical. The data migration produced subtle inconsistencies that took six weeks to find. The vendor lift-and-shift quote turned into a year of platform-specific re-platforming work the buyer didn't sign up for.
The right migration is rehearsed, audited, gated, and recoverable. Production-clone rehearsals run before any production cutover. Every data movement has dry-run + apply modes + audit reports + reconciliation checks. Staff workflow is a first-class requirement, not cleanup after launch. The legacy system stays running through cutover, then is retired after the new platform is proven against real orders.
The Fine's Gallery FileMaker retirement migrated 28,000+ historical invoice records into a platform-native invoicing system inside Payload + Postgres with strict payment-ledger audit exit code 0, 0 duplicate invoice numbers, and 12 orphan invoice deposits deferred by policy instead of forced into the ledger. Money movement is not an area where probably correct is good enough.
The approach
How this engagement runs
Plan the migration like a regulated production change. Rehearse it. Audit it. Cut over with rollback criteria defined in advance and the legacy system still operable until the new system is proven.
Legacy system audit
Inventory the actual data, the actual workflows, the actual edge cases, and the actual users. Read the records. Talk to the staff. Find the rules that aren't written down anywhere.
Target architecture design
Specify the destination: a sovereign AWS Organization, a Postgres data model that absorbs the legacy workflow without losing the workflow, integration boundaries, observability, and the staff operating surface.
Migration plan + rehearsal
Production-clone rehearsals before any production cutover. Per-cohort phased migration with reconciliation gates. Idempotent scripts with dry-run + apply modes. Strict payment-ledger audit if money is in scope.
Cutover with rollback criteria
Defined rollback criteria, defined success criteria, defined operational owners for the cutover window. Legacy system stays operable through cutover.
Post-cutover monitoring
CloudWatch alarms, drift detection, divergence monitoring against the legacy system for as long as the operation needs the safety net. Architectural Decision Records and a runbook the team inherits.
Outcomes
What you walk away with
- Zero downtimeProduction cutover (anchor client)Source: Fine's Gallery custom platform launch (June 2025)
- Strict payment-ledger audit exit code 0Legacy invoicing migration auditSource: Fine's Gallery FileMaker retirement (28,062 unique invoice numbers, 0 duplicates, 350 legacy payments backfilled)
- 20+ years of legacy data preservedOperational continuity through cutoverSource: Fine's Gallery FileMaker → Payload migration (28,000+ historical invoice records)
- Phased plan with reconciliation gates per cohortConfidential migration deliverableSource: Confidential energy-sector certificate registry migration design (Lead Architect)
- Multi-account sovereign AWS OrganizationCloud rebuild scopeSource: Fine's Gallery infrastructure rebuild (ECS Fargate, RDS, S3, CloudFront, SQS, Lambda, EventBridge, KMS, IAM, GitHub OIDC)
- Client-owned Terraform state, GitHub repo, AWS OrgArchitectural ownership transferred to clientSource: Sovereign architecture pattern across every Conti Digital build
Concrete deliverables
- Legacy system audit + risk register: data shape, workflow inventory, integration map, staff dependency analysis, edge cases that aren't written down anywhere.
- Target architecture: sovereign AWS Organization, ECS Fargate, RDS Postgres, S3, CloudFront, SQS + Lambda backbone, KMS / IAM via GitHub OIDC. Terraform-managed.
- Migration plan with per-cohort phased ingest, reconciliation gates, dry-run + apply scripts, idempotency, rollback criteria, and strict ledger audit when money is in scope.
- Production-clone rehearsals before any production cutover. The cutover runs against the same shape of data the migration script processed during rehearsal.
- Cutover runbook with defined success criteria, defined rollback criteria, defined operational owners, and a recovery path that keeps the legacy system operable through the window.
- Staff workflow preservation: the safest migrations keep familiar operating patterns where they matter while removing the platform limits underneath them.
- Post-cutover divergence monitoring against the legacy system for as long as the operation needs the safety net. CloudWatch alarms, drift detection, observability discipline.
- Architectural Decision Records, runbooks, and handoff documentation the team inherits. The next person who has to operate this should be able to read the record and pick up where the engagement ended.
FAQ
Frequently asked questions
The legacy system stays operable while the new platform absorbs the workflow. Cutover happens after the new platform is proven against real production data in production-clone rehearsals. Customers do not see an outage. Staff do not see a workflow gap. The Fine's Gallery cutover ran with zero operational downtime and zero loss across 20+ years of legacy operational data.
Rollback criteria are defined before the cutover starts, not invented at 3 AM during the cutover window. The legacy system stays operable through cutover. Per-cohort phased ingest means a problem in one cohort doesn't take down the whole migration. The rule across every migration is the same: if the system can't prove a data movement is safe, it doesn't apply it automatically. That's why the Fine's Gallery migration deferred 12 orphan invoice deposits by policy instead of forcing them into the ledger.
The plan and the rehearsal are usually 4 to 12 weeks. The cutover itself is a defined window (often a single day or a defined off-hours run) gated by rehearsal success. Total elapsed time from engagement start to production cutover depends heavily on data volume, workflow complexity, integration count, and how many cohorts the migration runs in.
The Fine's Gallery FileMaker retirement was one of multiple migrations inside a 19-month custom platform build.
Not as the primary engagement. Lift-and-shift is usually a worse outcome than rebuilding the platform with the legacy data preserved.
If the goal is to move existing infrastructure between hosting providers without changing the workflow, an AWS Partner with that specific specialization is a better fit. If the goal is to migrate off a SaaS or legacy operational stack onto sovereign infrastructure designed around the actual workflow, that's exactly what this engagement does.
Defined explicitly. Some legacy data needs to come over (historical invoices, customer records, payment ledger). Some legacy data is local to the legacy system and shouldn't move (test fixtures, deprecated workflows, abandoned integrations). The migration plan calls out what comes, what stays, and what gets archived for compliance.
Migration plans from $15K (Architecture Sprint scope: a written architecture decision document — current-state audit, risk register, target architecture, migration plan, cost model — delivered in 3 weeks). Cutover engagements scope after the assessment based on data volume, workflow complexity, and integration count.
If the engagement scopes naturally as a multi-month build with the legacy retirement as one phase, it usually runs as a Custom Application Development engagement starting at $80K. If the post-cutover work needs ongoing senior architecture governance, that scopes as a Fractional CTO retainer at $15K/month.
Solo delivery by Peter T. Conti, AWS Solutions Architect Professional + Associate. Lead Architect on a national-scale energy-sector certificate registry migration design. Principal engineer on the Fine's Gallery FileMaker retirement (28,000+ historical invoice records migrated, strict ledger audit exit code 0, 0 duplicate invoice numbers).
The same person who scopes the migration ships the scripts, runs the rehearsals, and owns the cutover.
Related work
See this in production
Fine's Gallery Platform Modernization
Solo-built end-to-end commerce platform for a luxury marble and stonework gallery. $5M+ annual revenue running on a sovereign, client-owned AWS Organization. Zero-downtime production cutover. 20+ years of legacy operational data migrated into the new platform without loss. Marketing dominance on the new platform supports $500K+/month in commerce volume. Systematic removal of vendor lock-in across SaaS commerce, payment, and warehouse tooling. Now operates on a Fractional CTO retainer.
Peter T Conti Consulting Platform
The consulting practice's own site, built as the reference architecture for what the practice sells. Same Next.js + Payload + Postgres + ECS Fargate + Terraform stack as the anchor engagement. STS-only IAM, no long-lived credentials anywhere. Cost-tuned to run for a small fraction of the naive default AWS footprint, with full editorial workflow operated as code.
Read more
In-depth on this topic
The SaaS Ceiling: Why High-Ticket Brands Need Sovereign Commerce Infrastructure
For high-ticket ecommerce, you need infrastructure built around your business model, not the other way around.
Stop Renting Your Revenue Engine: The Sovereign Infrastructure Blueprint for High-End E-Commerce
The goal is straightforward: you own the platform that owns your revenue.
Credentials and Fit
Directly relevant experience for high-trust delivery
I lead architecture and implementation personally, with technical depth that spans product, cloud, and execution operations.
AWS Certified Solutions Architect - Associate
Cloud decisions are grounded in secure, cost-aware architecture with practical production tradeoff management.
Dual technical foundation
B.S. Computer Science plus B.S. Chemistry with undergraduate research and scientific presentation discipline.
AWS Certified Solutions Architect - Professional
My ability to use AWS to solve complex business requirements has been demonstrated at the highest enterprise level.
Migration & Rescue Inquiry
Share your current platform, uptime constraints, and immediate performance or scaling bottlenecks so I can scope a safe migration or rescue plan.
Pressure-test the platform decision before you commit budget.
Schedule a complimentary 30-minute consultation to align on objectives, stress-test your architecture, and leave with a concrete set of recommendations. No obligation, no sales pitch. Just actionable technical guidance.