Migration readiness (beta)

When it's time to plan a move off Dynamics GP, the Migration page shows how clean each company's data is to move, and how big a move it would be. It only reads GP, and every score comes from fixed rules, the same for every company. It's a beta: the rules are still being tuned on real companies.

About 60 seconds, narrated, with captions. Sample company, made-up data.

Turn it on

A Ledger Doctor admin opens Settings (the gear at the top right), marks Show the Migration page under Migration readiness, and saves. Migration (beta) then appears in the menu at the top for everyone. Choose Assess now: it reads the company in GP and uses the latest scan, so run a scan first. A large company takes a minute or two. Ledger Doctor keeps the last ten assessments of each company.

The grade

Two results, shown together. Data health (A to F) weighs five areas: the chart of accounts (30%), GL history (25%), open receivables and payables (25%), customers, vendors and items (10%), and bank and other balances (10%). Each area starts at 100 and loses points for what it finds, and the page lists each finding. A is 90 and up, B 80, C 70, D 60. Migration complexity (low, medium or high) counts what makes a move bigger: several companies, several currencies, GP payroll or manufacturing, add-on products, custom SQL code, SQL Agent jobs, high volume, and segments that become dimensions. A clean but complex company is still a big project, and a simple but messy one needs cleanup first.

Your options

The page ends with three paths, each marked Recommended, Possible or Not yet, with the reason from your results: get on track with Ledger Doctor Essentials (a plan) when the data needs cleanup first, stay well on GP with Ledger Doctor Close (a plan) when a long project is ahead, or migrate when the data is clean and the move is manageable.

Share my assessment

If you'd like an introduction to an implementation partner who fits your business, an approver chooses Share my assessment. Pick your type of business, check the summary that will be sent, and add anything Ledger Doctor couldn't see: other integrations, other entities, accounting done outside GP, or other systems to merge in. Please don't enter names, account numbers or amounts. Nothing is sent until you agree and choose Share.

The summary holds counts and categories only: how many companies, GL accounts, customers, vendors and items, how many GL lines and open documents, the modules in use, the integrations Ledger Doctor found, your grade, and what you added. It never includes names of customers, vendors or employees, account numbers, amounts or transactions. Ledger Doctor keeps it encrypted, deletes it after 90 days, and replies to your license contact. You keep a copy of exactly what was sent: Download my copy on the same page.

Connect to your implementation partner

Once you've chosen a partner who uses the Ledger Doctor partner application, they give you their partner code. An approver enters it under Your implementation partner on this page and chooses Connect. Nothing is sent until the partner accepts. Then Ledger Doctor sends them a short quoting summary of the company: its name, how many GL accounts, vendors and customers it has, its years of GL history, the modules in use and a few account numbers, so they can quote the move.

Confirming your partner's project

Your partner picks the GP companies for your project. This page then shows which ones and exactly what data goes to them once they've paid for it. An approver for each company checks they're the right companies and chooses Confirm the companies and data, or Send it back with a note if one is wrong. Once your partner has paid, a covered company stays in the project. Both choices are in the security log.

Once the project covers a company, Ledger Doctor sends that partner this company's migration assessment, chart of accounts, fiscal calendar, which accounts are bank, retained earnings, receivables and payables accounts, GL summary balances, and, once your partner chooses the date the conversion starts, GP's trial balance at the start of that date once a day, and whenever the partner asks for fresh data. You can also choose Send now.

It also has these records, so your partner can set them up in the new system:

Customers and vendors, with their addresses, contacts, email addresses, payment terms, classes and credit limits. Vendors' tax ID numbers and bank details aren't sent.
Employees, if you use GP payroll or HR: their names, class, department, job, location, supervisor, start date and work email. Never their Social Security numbers, birth dates, pay, home addresses or phone numbers, or anything else personal.
Items and warehouses, with each item's description, class, units of measure, costs and quantity on hand.
Fixed assets, with their book values: cost, depreciation to date, method and life.
Bank accounts: every GP checkbook, with its bank's name and address, its GL account and currency (with the currency's three-letter ISO code, such as USD, from GP's currency setup), the next check and deposit numbers, when it was last reconciled and the balance then, GP's checkbook balance and the GL account's balance today. Only the last 4 digits of the bank account and routing numbers are sent, so your partner can check they have the right account. The full numbers, direct deposit details and checkbook passwords never leave your server: you or your partner enter the full numbers in Sage Intacct from the bank's own documents.
1099 balances: what GP has recorded for each 1099 vendor this calendar year and last, by month, form type and box, with your 1099 box setup, so your partner can load the year's 1099 amounts into Sage Intacct after you go live. Vendors' tax ID numbers aren't sent.

Only records your partner needs are sent: those used since the date the conversion starts (on a GL entry or a document, or with an open balance or quantity on hand), active employees, assets not retired, and anything created in the last 18 months. Your partner can change the 18 months for your company, from 0 (only what's used) to 120. Your Migration page shows the number of months they use, under Your implementation partner. Ledger Doctor before 0.39.1 always uses 18. Until your partner sets the conversion start, Ledger Doctor uses the first day of GP's earliest open fiscal year.

GL history and open receivables and payables

When your partner is ready to load your history into Sage Intacct, they ask for it with the dates they'll use. Only then, and only for a company the project covers, each package also has:

GL history: what was posted to each GL account in each fiscal period between the two dates your partner picks (normally the conversion start and the last month you've closed in GP), as one total of debits and one of credits per account per period. Not the journal entries themselves: those stay on your server. It comes with GP's trial balance at the start and at the end, and how many journal entries there were each year, so your partner can check every account ties to the penny and see what a detailed load would take.
Open receivables and payables: every customer and vendor document still open on the cutover date your partner picks, with what was still owed on it that day (a payment made after that date doesn't change it), its dates, number, description, PO number, receivables or payables account and the GL accounts and amounts GP recorded for it (its distributions, so each line goes to the same account in Sage Intacct), and the GL balance of those accounts that day.
Outstanding checks and deposits: for each checkbook, the transactions that hadn't cleared the bank on the same cutover date (number, date, type, payee or description and amount), its last reconciled date and balance, and its balance that day. Ledger Doctor checks each checkbook ties to the penny first: the reconciled balance, plus the deposits, less the checks, is the checkbook's balance that day. A checkbook that doesn't tie sends its totals and why, not its items. They become the first bank reconciliation's starting items in Sage Intacct. No bank account or routing numbers are sent.

Ledger Doctor works these out the same way as its tie-outs, so the open receivables equal what the AR tie-out for that date shows, and the history ties to GP's trial balances. When something in GP makes them unreliable (unposted GL, Receivables, Payables, Sales or Purchasing transactions dated in the history or by the cutover, a period still open, records that don't rebuild, or a date that hasn't come yet), it tells your partner what, in plain words, instead of sending figures that would be wrong. A document GP shows fully paid with no record of what paid it is taken as closed: it isn't sent, and your partner sees a warning naming it. A document GP shows partly paid with nothing applied to it goes at the amount remaining GP shows, with a warning that names it and the check "Amount remaining doesn't match the applications" (C75). Settle those here before the move: set the full amount if an application was removed, or mark the row as expected if the balance was loaded that way. When only some documents' history doesn't add up for the cutover date, those documents are named and left out, the rest are sent with what was owed on them that day, and no total is sent until they're fixed in GP. Each document's currency also goes with its three-letter ISO code from GP's currency setup, which is what Sage Intacct takes. When a request would make the package too big to send, the details are left out and only the totals go, with a note asking for a shorter history. GP's year-end closing entries aren't part of the history: Sage Intacct closes each year into retained earnings itself. Each time they're sent, the job log says so. When your partner stops asking, they stop being sent.

Budgets

Budgets come last in a move. When your partner is ready for them, they ask for every GP budget from a year they pick. Only then, and only for a company the project covers, each package also has those budgets: each one's ID, description and dates, and its amounts by GL account and fiscal period, exactly as GP stores them, with each budget's total. Amounts that cancel to zero aren't sent. GP's beginning balance amounts aren't either, because Sage Intacct budgets don't have them: your partner is told which budgets had them and how much. When a budget line is on a GL account GP no longer has, or in a period GP's fiscal calendar doesn't have, your partner is told in plain words. When there are too many lines for one package (more than 200,000), only each budget's total goes, with a note asking for budgets from a later year. When your partner stops asking, they stop being sent.

Unlike the summary above, this includes names and account numbers, because your partner needs them to plan the move. Each package is encrypted on your server for your partner's application and signed by your Ledger Doctor, so myledgerdoctor.com, which passes it on, can't read or change it. It deletes a package as soon as the partner takes it, or after 14 days. Either side can end the connection at any time with End connection; nothing more is sent after that.

GL history in detail

Your partner can choose to load the history one GP journal entry at a time, instead of one total per account per period. Then Ledger Doctor reads every journal entry line in the history's dates here, on your server: the same lines the totals above add up. It checks that every entry balances and that, for each account and period, the lines add up to the totals to the penny, and keeps them in one file in Ledger Doctor's data folder on this server (replaced with each package). Only a summary goes in the package: how many entries and lines, the size of the file, and the totals by period. An entry that doesn't balance, lines that don't add up to the totals, or a history of more than 2,000,000 lines is named in plain words instead, and then no file is kept.

The journal entries themselves go to your partner only when they ask for them and agree to the size. Ledger Doctor then sends the file in parts, encrypted for their partner application like every package, at its next check-ins. If GP's GL changed since the package your partner saw, it tells them so instead and sends nothing. GL detail sent to your partner on this page lists each time they asked: when, which partner, how many lines, the size, and whether it went. Each one is in the security log too. When your partner stops asking for detail, the file is deleted.

Vendors' tax ID numbers, Social Security numbers and bank account and routing numbers never go to your partner. To get them into Sage Intacct without that, your partner sets up a web services user in your own Sage Intacct company (it's your account) and sends its sign-in to this Ledger Doctor, encrypted so only this server can open it. You don't set anything up, and your partner doesn't need to reach your server.

It's kept in its own file on this server, sealed to this computer with Windows' own encryption, in a folder only administrators and Ledger Doctor can open. It's never in Ledger Doctor's settings file or database, never shown on a page, never in a log, an export or anything sent to your partner.
When your partner asks, Ledger Doctor reads the vendors they name from GP (the tax ID, the 1099 form and box from the vendor's setup, and the vendor's EFT bank on its remit-to address) and sets them in Sage Intacct directly. Your partner sees only, for each vendor and field, whether it was set, that GP has nothing for it, or Sage Intacct's error with the numbers taken out. A routing number that isn't a valid 9-digit US one isn't sent, and neither is a 1099-MISC box 7 (it's been 1099-NEC box 1 since 2020): fix those in GP first.
This page shows Your partner sent a Sage Intacct sign-in for the company and environment, when it came and when it was last used. A Ledger Doctor admin can choose Delete it; your partner can send it again.
It's deleted by itself when your partner withdraws it, when either of you ends the connection, and when your partner tells Ledger Doctor you've gone live.
Each time it arrives, is used or is deleted is in the security log. The same sign-in will later carry detailed transactions such as GL detail and open documents, so it isn't limited to vendors.

What's in the way, from your partner

When something is holding up the move, your partner can send a list of it, and it shows at the top of this page: problems in GP to fix, each with what to do and a link to its issue here (and its guide or one-click fix, when it has one), and decisions only you can make, with their choices. A processor ticks Done when a problem is fixed; an approver picks a choice or writes an answer and chooses Save answer. Each one goes back to your partner at once (or at the next check-in, if myledgerdoctor.com can't be reached), encrypted so only their partner application can read it. Download PDF makes a copy, with the answers so far, to email to whoever fixes things in GP. When your partner sends a new revision, it replaces the list and keeps what you've answered.

When a problem is marked done but Ledger Doctor's latest scan still finds records for it, it says so beside the item, like "Ledger Doctor still finds 3 records", here and in the PDF. Your partner sees the same from the latest package you sent them. Marking items done and answering decisions are recorded in the security log.

The security log says when your partner's paid project starts covering a company, since that's when its full data starts going to them.

Under each partner connection, a Ledger Doctor admin can tick Allow my partner to download my data for implementation and data migration. Turn it on when your partner has to load Sage Intacct from import files, for example when you don't have a Sage Intacct Web Services license. While it's on, data that normally never leaves this server goes to that partner too: your vendors' tax IDs, their 1099 setup, and the bank account and routing numbers you pay them by EFT. It goes encrypted, only to that partner, for that connection only, and they can download it as import files. Turning it off stops sending it, and the next send tells their application to delete what it holds. It's off unless you turn it on, and each change is in the security log.

Sharing your Management Reporter report definitions

Under each partner connection, a Ledger Doctor admin can tick Share my Management Reporter report definitions with my partner (no amounts). Your partner compares how your financial statements are built in Management Reporter (its row definitions, column definitions and reporting trees) with the new chart of accounts and dimensions, so nothing your reports split by is merged away in the migration. While it's on, Ledger Doctor reads those definitions from the Management Reporter database on your GP SQL Server, read only, for this company's Management Reporter company, and sends them with each package. No amounts go, and nothing about who made or ran a report, report schedules or recipients. Ledger Doctor's service account needs db_datareader in the Management Reporter database; if it can't read it, or there's no Management Reporter database on that server, the package says why and goes as usual. It's off unless you turn it on, and each change is in the security log.

When you go live in Sage Intacct

When your partner marks the move done in their partner application, this page says so: your partner reported that the company went live in Sage Intacct, and on which day. Nothing changes on its own: Ledger Doctor keeps working. If your partner takes it back, the note goes away.

GP is often still used for a while after go-live, for a last check run or depreciation before fixed assets move. Your partner sets GP's last day for this migration, and this page shows it, with any GP modules still in use after go-live and until when. The day after GP's last day, Ledger Doctor deletes the Sage Intacct sign-in your partner sent it for this company, and no longer sends your partner data for it or takes new requests from them. The connection stays until either of you ends it.

Chart of accounts

Ledger Doctor reads the account numbers GP formats and splits them into segments. The segment with the most values is the natural account; the others are candidates for dimensions in the new system. It counts how many natural accounts would remain, accounts with no activity in three years (leave them behind), descriptions used by more than one account, and values buried in account names, like "Rent - Denver" and "Rent - Boston", which become a location dimension.

GL history

Each year in GP, open or in history, with whether its summary balances match the detail (check C07) and how many posted entries don't balance (C06). Years that pass both can move as monthly balances.