The system runs the business.
One person runs the system.
An MS Access app, a FoxPro database, a custom ERP nobody dares touch — built years ago, undocumented, and tied to one developer. A rewrite feels too risky. dForge lets you modernize one workflow at a time, on real infrastructure, without a big-bang cutover.
Internal slides hidden. Open with the deck key to show them.
What we'll cover.
- 01The risk the business is carrying right now
- 02Why the rewrite keeps getting deferred
- 03Migrating without a big-bang cutover
- 04What a migration actually costs
- 05The next 30 days
Is your business at risk?
If you recognize a few of these, the system is carrying more risk than the business realizes.
- A single developer (or none) keeps a critical system alive.
- It's 10+ years old, undocumented, and "don't touch it or it breaks."
- A trigger just changed — that person is leaving, an audit, an acquisition.
- You've priced a rewrite and it's too big, too risky, all at once.
Two or more? It's worth a conversation before the trigger forces one.
Modernize without the big bang.
Start from your existing schema, move one workflow at a time, and end up on infrastructure anyone can read and support.
Map your schema into a module
Hand over your existing SQL, DBML, or even the legacy screens. We model your entities, fields, and relationships into a real dForge module — AI-assisted and reviewed with you, not a black box.
Migrate one workflow at a time
Move a single process first, prove it in production, then expand. dForge runs alongside the legacy system during the transition — no risky cutover.
Real, documented, supported
Postgres under the hood, metadata you can read and review, role-based security built in. The bus-factor problem goes away.
What that looks like in practice.
- Bring what you have — SQL, DBML, or the legacy screens themselves.
- We map entities, fields, and relationships into readable metadata.
- You get a real module to review and refine — not a black box.
- Move one process to production and prove it works.
- Runs alongside the legacy system during the transition.
- Expand workflow by workflow — never a big-bang cutover.
- Standard PostgreSQL — inspectable, backed up, portable.
- Metadata you can read and review — not code only one person understands.
- Role-based security and audit, built in.
The system today, and after.
A rewrite, priced against a migration.
The rewrite quote is the number you already turned down. This is the alternative — phased, so you can stop after any step.
The assessment is fixed-price and credited against the migration if you proceed — so the first decision costs a known number, not a leap of faith.
Modules worth installing first.
Warehouse Management
Warehouse management: procurement requests, PO workflow, stock operations, inventory tracking. Vendor identity lives in the shared parties module; WMS-specific columns (supplier code, payment terms) are layered as an extension.
Finance
Accounts receivable, accounts payable, invoicing, and payments
The questions people actually ask.
Scroll down for the answers — or jump straight to one.
How long does this actually take?
The first workflow reaches production in weeks, not the whole system at once. Before that, a fixed-scope assessment maps your data model and workflows, so the timeline you get is based on your actual schema rather than an estimate made from a description of it.
What happens to the data we already have?
It moves into a standard PostgreSQL database you can query and back up like any other. The assessment maps every table first, and your existing system keeps running alongside the new one through the transition — nothing is switched off before you've seen the replacement work.
Can we stop partway through?
Yes, and that's the point of phasing it. Every phase ends with something running in production rather than a half-finished rewrite. The assessment is fixed-price and useful on its own: even if you go no further, you own a documented map of a system nobody has documented in years.
Who can maintain it afterwards?
Any developer, or us. The database is standard PostgreSQL and the business rules live in metadata a person can read and review — not in code that only its original author understood. That is the whole point of moving: the system stops depending on one person.
The person who built our system isn't available. Is that a problem?
No — it's the usual case. We work from the database and the running screens, not from anyone's memory. Undocumented systems are what this process is designed for; if yours were fully documented you probably wouldn't be considering this.
A plan before a single line moves.
Nothing is migrated until you've seen the map and agreed the scope.
Discovery call
A short call to map the system, the stack, who maintains it, and what changed to make this urgent now. No demo, no pitch.
Migration assessment
A fixed-scope audit of your data model and workflows that ends in a concrete migration plan — so you decide with facts, not a guess.
Migrate in phases
One workflow to production first, proven, then expand — on documented, supported infrastructure, hosted by us or on your own servers.