The reason people put off moving servicing software is not the software. It is the history. Years of payments, splits, late fees, and a current balance that a borrower and possibly a closing agent are relying on, plus a well founded suspicion that a migration is where all of that quietly goes wrong.
That worry is correct in general, and it is the thing an import has to answer specifically. Here is how the move works, in the order you will do it.
Step 1: run the right export, in the right format
Two rules make the rest of this easy.
Export the payment history report, not a summary. It is the report that carries the per payment principal, interest, escrow, and fee splits. A loan summary gives balances without the splits, and splits that are not in the file cannot be recovered from it.
Export it as CSV rather than PDF. A CSV is read directly, so the columns arrive exactly as your other software wrote them. A PDF has to be recovered out of the page's text layer, and on our own test exports that path recovered about 92 percent of fields rather than all of them. If both formats are available, take the CSV.
One more setting is worth getting right the first time. If the export offers a period, set it to run from origination to today. An export that starts partway through the life of the loan is still importable, and the wizard handles it, but you will get the payments for that window rather than the whole life of the note.
Step 2: upload it
The wizard reads the file and recognizes what it is by its shape rather than asking you to declare it. A NoteSmith payment history report is a printed servicing report saved as CSV rather than a relational table, with header blocks that repeat at each page break and a totals footer at the end, and it is read on those terms.
Nothing is written to your book at this point.
Step 3: read the preview before you agree to anything
The preview is the part worth slowing down for. It shows four numbers across the top: the covered period, how many payments were parsed, the opening balance for that period, and the current balance taken from the report footer. Underneath, the loan itself: borrower, reference, original principal, interest rate, regular payment, and next due date.
If the export did not start at origination, the preview says so in as many words and tells you how to re-export for a complete history. The alternative is a silent partial import that looks complete until someone asks for a lifetime interest total.
Step 4: the balances are proved, not assumed
This is the step that answers the actual fear, so it is worth understanding rather than trusting.
The importer does not compute its own amortization and compare it to yours. It checks your file against itself. It takes the first row's printed balance, adds back that row's printed principal to establish where the period opened, then walks every row subtracting the principal that row printed, and requires the result to equal the balance that row printed, in whole cents. At the end, the running total has to equal the balance in the report footer.
Every one of those numbers came out of your existing system, so the importer is verifying that the arithmetic in your own file ties out before adopting it. If a row misses, the preview lists the discrepancies and the import is blocked. Nothing lands until it reconciles.
What carries over
The loan, at its current state. Terms, rate, payment, next due date, and the balance from the footer.
The servicing conventions the report names. A payment type field like USRule 365 M is not decoration: it says the loan accrues under the United States Rule, on an actual over 365 day count, monthly. Those three settings are read out of that field and applied, so the loan is seeded the way it was actually being serviced instead of silently defaulting. Where the field is blank or ambiguous, the NoteHarbor default stands rather than a guess being made.
The payments, with your splits intact. Each payment keeps the interest and principal amounts your file printed, verbatim. They are not recomputed, because recomputing them would mean asserting your old system had the math wrong.
Multi installment receipts, as one receipt. One check that covered three installments stays one cash event with three applications rather than three payments that never happened.
The reason codes. Regular, partial, principal only, late, service, escrow, reversal, and adjustment codes are preserved, and every imported payment carries a memo naming where it came from, so the ledger stays auditable a year later when nobody remembers the migration.
What does not carry over, and why
The balance is not rebuilt from the payments. It is taken from the report footer. This sounds like a shortcut and it is the opposite: an export that does not start at origination does not contain the whole story, so replaying it against the original principal would double count. The footer is the number your old system stands behind, so that is the number adopted.
For the same reason the imported payments attach as historical ledger records rather than as a reconstructed origination schedule, and the engine refuses to replay or regenerate a schedule for a seasoned import with no origination history behind it. A rebuild would produce a confident number that nobody can source.
Documents and attachments. They move separately rather than riding along in the ledger file.
Anything your export does not contain. Which is the honest answer, and the preview is where you find out what that is for your particular file.
Step 5: the parity checks worth doing
Do these once per loan, immediately, while you still have the old system open.
The current balance against the footer of the report you exported. It should match to the cent, and the preview already proved it does, so this is confirming you imported the file you meant to.
The next due date and the regular payment. These drive everything forward and they are the fields most often wrong after any migration.
Year to date interest, against whatever your old system reports for the same window. If these disagree, the year end form disagrees too, and January is a bad time to discover that.
A payoff quote to a specific date. Pick a date two weeks out and compare. Payoff is where every accrual difference surfaces, so it is the most informative check on the list. You can check a payoff figure against the free payoff and reinstatement calculator independently of either system, which is a useful tiebreaker when they disagree.
Escrow, if you hold it. The balance, the next disbursement, and the date of the last analysis.
Step 6: run parallel for a month
Import, then keep posting in both systems for one full cycle. Not forever, and not for a week.
A month is the right length because it is long enough to contain the events that actually differ between two systems: a payment received on a different day than it was due, a late fee assessed or waived, a partial payment, an escrow disbursement. Comparing two systems on a clean on time payment proves almost nothing, because that is the case every system gets right.
At the end of the cycle, compare the four numbers from step five again. If they agree, stop paying for both.
Two practical notes
Importing during a free trial is capped at 10 loans, cumulatively, so a large book is a test drive during the 30 day trial rather than a full migration.
And nothing about the import reaches back into the software you are leaving. Your old system stays exactly as it was, readable, for as long as you want. There is no point in the process where you are without a copy.
The import page covers the other file formats the wizard reads, and the NoteSmith comparison covers what changes once you are across. If you have not decided that moving is worth it yet, what to check before you switch is the list of questions rather than the walkthrough, and pricing is published in full.
This article is general information, not legal, tax, or accounting advice. What your year end forms must report, and for which loans, depends on facts specific to you. Talk to a licensed attorney and your CPA about your own situation before relying on any imported figure for a filing.