Migration is the project. The software is the easy part.
Moving a live loan book means borrowers, balances, schedules, payment history and documents arriving intact and balancing against the system you are leaving. QFund treats that as an explicit, evidenced phase — not an assumption.
How an implementation actually runs
Durations depend on loan product count, state count, integration count and the condition of your current data. We scope against your actual system before committing to dates.
Discovery and scope
Loan products, states, channels, integrations and reporting requirements documented. Your current system, its data model and its known data problems are examined rather than assumed. This is where a realistic timeline comes from.
Configuration
Loan product parameters, rate and fee structures, underwriting matrix, document templates and state rule sets configured — including every separate loan product you run inside a loan type, and the brands, channels, states and stores each one is offered to. Your team is involved here deliberately — the people who will maintain the configuration should build it.
Integration
Pre-built connections to your bureaus, verification vendors, payment processors and communications platforms enabled and tested. Anything outside the 90+ pre-built set is built as an interface engagement. If you are building your own portal or agent interface on QFund’s APIs, this is the phase where your development team gets the endpoint reference and payload schemas and works against a QFund environment with your dedicated team alongside.
Data migration
Source and target hosts and data identified, mapping discovery performed and documented, then test loads with balancing against your current system. Borrowers, balances, schedules, payment history and documents all move.
Simulated go-live
A full dress rehearsal on migrated data: branches transact, close-of-day runs, statements generate and the accounting entries are checked. Problems surface here rather than on the morning you cut over.
Go-live and stabilisation
Cutover with the rollback position defined in advance, then hands-on support through the first close cycle, the first statement run and the first month-end.
Test and balancing is not optional
The migration phase includes explicit balancing of migrated data against your existing system. If the two do not agree, you find out during testing — not from a borrower disputing a balance after cutover.
What moves, and how it is proven
- Scope
- One-time or repetitive migrations, depending on whether you are replacing a system or feeding QFund from another platform on an ongoing basis.
- Identification
- Source and target host and data identification as a documented first step.
- Mapping
- Mapping discovery: field-by-field correspondence between the old model and the new one, including the fields that have no clean equivalent.
- Documentation
- The mapping is written down and signed off, so migration decisions are auditable afterwards.
- Test & balancing
- Test loads reconciled against source-system totals — balances, accrued interest, fee positions and counts.
- Simulated go-live
- A rehearsal on migrated data, with real close-of-day and statement processing.
- Final go-live
- Cutover on proven data, with a defined rollback position.
What the engagement covers
Included in the ASP model
- Software ASP licence
- Hosting and hardware
- System software components (JBoss, Oracle, Linux)
- 24×7 support and monitoring
- Data backups and data archival
- Help manuals
- Technical and functionality upgrades
- Training (available, not a prerequisite — the screens share one layout)
On-demand (billable)
- Customisation and custom development
- Integration and interfacing work beyond the pre-built set
- Change-request management
- Extended training
- Data migration
- Roll-out and implementation services
The team that implements it is the team that stays with it
QFund fields a dedicated team per lender, drawn from 400+ financial-lending domain experts. After go-live they already know your configuration, your states and your integrations — so a new loan product, a new state or a re-worded agreement is usually configuration and testing, not a discovery exercise. See dedicated teams.
Implementation questions
How long does it take?
It depends on variables we will not guess at in marketing copy: how many loan products and states you run, how many integrations you need, and how clean your current data is. One loan type in one state and a twelve-state operator with a decade of history are different projects.
Do we run both systems in parallel?
Typically there is a simulated go-live on migrated data rather than an extended dual-running period, because running two live systems on the same book creates its own reconciliation problem. The rehearsal is designed to give you the same confidence without that risk.
Who does the configuration — you or us?
Both, deliberately weighted toward your team. The people who will own the configuration after go-live should build it during implementation, with QFund alongside. That is the difference between owning your platform and depending on us for every fee change.
How fast can we launch a new loan product once we are live?
As fast as you can configure and test it. A new loan product inside an existing loan type — its principal bands, interest method, fees, documents and the brands, channels, states or stores it is offered to — is set up in the application and tested, by your team or by QFund application support. No code branch, no vendor release cycle.
What happens if migration reveals bad data?
It usually does, and that is the point of doing it in a test phase with balancing. Discrepancies are identified, the correct treatment is agreed and documented, and the mapping is adjusted — before cutover rather than after.
Ask us the hard implementation questions
How you balance a migrated book, what the rollback position is, and who owns the configuration afterwards. Those answers matter more than a feature list.