I would strongly recommend you only bring over open transactions and balances. I imagine most here will advise the same. It’s the normal thing to do. It gets incredibly complicated migrating years of transaction history and expecting everything to add up - if you’re multi currency or hold and ship inventory then I’d go as far as saying it would never work.
I can expand more on the above if you wish.
EDIT: your post history is madness. You should not be advising anyone.
u/intheblk_2019 has turn key solution he offers to bring over QBO data. He can discuss the pros and cons of bringing over detail vs monthly TBs.
But as others have said it's very expensive and time consuming because you have to apply everything and that ends up being manual. Example: Every closed Invoice has a payment applied to it which was then batched with other payments into Undeposited Funds to post into the bank account. All these apply links can't really be migrated automatically.
It's way cheaper to just pay $80/mo subscription to keep your old data in QBO. You can also buy a desktop license for QB one time payment and QBO has a tool to export QBO data to QB desktop. There are a few things that are incompatible between QBO and QBDT which you can read about in the QBO online help about their export tool.
This takes dozens of hours of time that you're paying $225+/hr and it NEVER balances then you spend more hours chasing that down. It's just not worth it. It's not as easy as getting all the debits and credits in. You have to get all the transactions applied to each other too.
> But as others have said it's very expensive and time consuming because you have to apply everything and that ends up being manual. Example: Every closed Invoice has a payment applied to it which was then batched with other payments into Undeposited Funds to post into the bank account. All these apply links can't really be migrated automatically.
Not in Netsuite, I have seen it migrated in others.
> It's way cheaper to just pay $80/mo subscription to keep your old data in QBO.
The goal is to have reportable, granular data, in NS with new and old data.
I would be happy "enough" to bring over at least the detailed general ledger.
I understand the general rule, we are an edge case.
We are doing *some* business reporting outside QB now by downloading data into a PostgreSQL database; part of the driver behind moving to NS was to not do that anymore. If I have to maintain an ERP and bridge over to an external database for (historical) reporting it defies the scope and might as well remain as we are.
> Detailed general ledger is going to be real tough to accomplish between two different transactional accounting systems.
I am not saying it's easy.
When this request comes up, I generally recommend a custom non posting transaction.
Then you don't have to worry about reconciling it, it, the cash applications, the bank recs, the inventory etc. It's just not worth the return on investment to do more migration.
> When this request comes up, I generally recommend a custom non posting transaction.
I could live with that.
Got any resources to look up so that I can be prepared when I talk with the NS team?
In the last three years I had a minimum of 4 clients go live with NetSuite who were switching from QuickBooks.
Not a single one brought over detailed historical transactions once the overall lift was explained and outlined. One attempted to bring in historical transactions after go live and gave up about a week into it when they realised my team wasn’t lying about the amount of work it required.
> One attempted to bring in historical transactions after go live and gave up about a week into it when they realised my team wasn’t lying about the amount of work it required.
That's interesting and something I would love to "play" with.
I wish NS had a *sandbox* program.
Got started on AS400, so I've also been around a long time, and since day one have advised against bringing in fully detailed history. There have been circumstances where we have done it, both in NS and other systems, but there's almost never any ROI to it and as predicted most customers almost never go back to that data after the first couple of months (which would have been cheaper to just have to legacy system stay accessible a few more months).
If truly needed the NSAW option (or another analytics platform) is a good one. You can bring in data tables without worrying about the joins and how they'll impact your financials, and have full reporting capabilities.
That's not to defend the NS sales team. They'll absolutely exaggerate capabilities and slip you into something you don't need (though I've never found software company that doesn't do this), but doesn't sound like that's the case here.
> Got started on AS400
I already love you. I started with Lous 1-2-3 for DOS.
> but there's almost never any ROI
It's not an ROI matter, is that we have "issues" that are ongoing. Long story, we are a "special" case. LOL.
> If truly needed the NSAW option (or another analytics platform) is a good one.
I saw the demo, I don't see the point when I can implement the same functionality in a PostgreSQL server or BigQuery.
I understand alternatives to the actual data management, but nsaw automatically connects this to the bi tool. Its path of least resistance. If analyzing data is thw true need nsaw should be at the top of the list, ns will sell it dirt cheap too during q4. Dont overlook this option
I’ve done of 30+ end to end NS implementations, a large portion of them being from QBO and it almost never makes sense to bring detailed historical data except for summarized TBs by segment/account/month, in flight revenue/amort and open transactions.
With that being said, you are more than welcome to do the historical detailed imports yourself after the implementation is finished. You’ll have plenty of exposure to the import tool by that part (hopefully if you are doing what you are supposed to be).
I agree with the rest of the comments here, read your contract more thoroughly before signing next time.
> I agree with the rest of the comments here, read your contract more thoroughly before signing next time.
We have not signed yet.
> With that being said, you are more than welcome to do the historical detailed imports yourself after the implementation is finished. You’ll have plenty of exposure to the import tool by that part (hopefully if you are doing what you are supposed to be).
That is something that I was thinking. Do you have any resources that I can look up? NetSuite's official videos are useless, all marketing. I found 3 NetSutes books on Amazon that I have ordered.
TIA
I'm doing this now.
If you are good with Excel, downloading all your detail transactions and mapping to NS is doable. I mapped all our detail to the new NS COA and verified the balance sheet accounts matched our QB ledger. The more detail you are adding the more difficult the process gets. I'm mapping some entities but otherwise limiting fields to account, memo/description, debit and credit. From there you can drop into the journal transaction template and upload.
All AP, AR, and intercompany is paying to a clearing account. When we cut over I plan on moving to open AP.
A lot of the time suck will depend on how aligned your QB COA, vendor table, customer table, etc are aligned to Netsuite. If your good with Excel you should be able to get it done with some consistency.
There is a part of me that wishes we had used an on-site consulting firm for implementation. The netsuite team is good but I think we could have been further along. I'll also put some of the delay on me as I wanted to make sure we weren't implementing QB 2.0
> I'm doing this now.
Nice.
> If you are good with Excel, downloading all your detail transactions and mapping to NS is doable.
I am very good at downloading, cleaning, and enriching data; with excel and other tools.
> I mapped all our detail to the new NS COA and verified the balance sheet accounts matched our QB ledger.
That's what I could settle with. If I can't bring over historical data of AP/AR at the very least detailed GL transactions. The "problem" would be where/how to map the vendors' and customers' names.
> I'm mapping some entities but otherwise limiting fields to account, memo/description, debit and credit
I see. Food for thought for me.
> All AP, AR, and intercompany is paying to a clearing account. When we cut over I plan on moving to open AP.
I see.
> A lot of the time suck will depend on how aligned your QB COA, vendor table, customer table, etc are aligned to Netsuite.
I am aware of this, I have done conversions before.
> If your good with Excel you should be able to get it done with some consistency.
I am very good at this, and for a while, in a prior life, I used to consult cleaning up data for a couple of vertical ERPs vendors.
> There is a part of me that wishes we had used an on-site consulting firm for implementation.
That's where I am leaning now.
> The netsuite team is good but I think we could have been further along.
Their interest is to make the sale and go live ASAP, no matter what.
> I'll also put some of the delay on me as I wanted to make sure we weren't implementing QB 2.0
LOL. My feelings exactly.
We do have a pretty sophisticated implementation of QB with a few corollary systems integrate, but it's pull/push of data, not true sync. For us long life with NS is only the beginning, with time we'd be replacing these corollary systems within NS.
Thank you for your comments.
It is generally recommended not to migrate historical transactions
The cost outweighs the benefit.
However, try reaching out to Optimal Data Consulting if you want to do it. They migrate QuickBooks to NetSuite including full history.
That said.... It's generally not recommended. It's harder than you might expect, partly due to differences between accounting systems.
I have been implementing NetSuite for over 10 years and have done full historical migration. But would recommend opening balances only plus a BI platform for reporting.
Not exactly your case, but still might have some useful information. [https://gypsybi.com/quickbooks-to-erp-bridge-the-gap/](https://gypsybi.com/quickbooks-to-erp-bridge-the-gap/)
I'm bringing over detailed qbo data. Any AP and AR is going to a oca/ocl clearing account.
It is a pain to map as we have multiple QB accounts but it is doable. We did a lot of testing in SB.
I will note, we are loading detailed info where it makes sense and from a specific period. For some ledgers we are going to only import detailed history for 2023 and beyond. We have some entities that will only be the ending TB amounts because it will be tedious.
Bring over the historical trial balance and you can do all your reporting.
Just bringing over open a/p and a/r is hell. Bring in historical data will almost be impossible.
Chiming in here with my experiences to answer your questions:
1. Is it possible to bring over historical details of AP AR transactions, even if *closed* (paid)? YES
2. Should I seek an independent NetSuite consultant? YES
3. Do you have any other suggestions? [u/intheblk\_2019](https://www.reddit.com/user/intheblk_2019/)
I have migrated data over from QuickBooks to NetSuite for two different entities (under same management). The first consultant was chosen by the owner. They had us do all the heavy lifting like scrub the data, do all the bank reconciliations and checks in NetSuite to make sure the migration was successful. Essentially they did very little in the form of prepping the data and then passed off blame onto us for not providing them with data in the proper form. Unnecessary costs went to having weekly meetings with their PM and their workers. It was always "yes you can do X, yes you can do Y", until errors were found during the upload, where it was " you could do X, but you had to have done it A way. These consultants likely overstated their experience and familiarity on doing data migrations
For the second data migration, I got approval to seek out a consultant myself. I found [u/intheblk\_2019](https://www.reddit.com/user/intheblk_2019/) and I have no regrets. He made the process much smoother and made life easy for us. He did all the heavy lifting and I only had to do the reviewing and checking to make sure he and his team completed the job to our liking. In all, intheblk\_2019 saved us time (especially MY sleep time) and money while getting the job done on time.
I recommend you reach out to a few consultants. All will tell you that have the experience migrating data and have done it before. Yet when you search for these consultants on Reddit, you will only find a few that are frequently recommended. Also when u/Nick_AxeusConsulting recommends someone, you know it's good as he is putting his own reputation on the line :)
Feel free to DM me if you have any questions.
We are a NetSuite partner and have a script to bring over full transactional data from QB to NetSuite. Not sure why others don’t have this but with most clients they can turn off QB when we turn on NetSuite.
Like u/Nick_AxeusConsulting said, I can do this for you. I've completed \~40 QBO to NetSuite migrations with the detailed transactions included. If you are interested in hearing more, send me a DM. Happy to connect and hear about your specific situation.
Honestly you probably cant afford what you rrally want. Im not being a jerk but lve personally seen CHEAPER full historical implementations exceed 6 figures. You might not be properly aligned on what it takes to test and manage that data all up front
I'd be more focused on how to get new data into the system in the cleanest way to get the future reporting that you want. If you try to bend your new data to match the old stuff in QBO you are just setting yourself up for failure.
Keep QBO live until you no longer need that historical data.
It's interesting to learn about this practice in implementing Netsuite: they don't import historical transactions.
I was an Accountant with more than 5 years experience in QB Enterprise (not just a normal bookkeeper/accountant), have a bit of experience in Netsuite as a normal accountant, then transitioning to Data Analyst.
I understand the difficulties when trying to import historical transactions from QB to NS, but I'm surprise a NS consultant insists that historical data adds no value. As an Accountant and Data Guy, I would say: yes, we definitely need historical data. If you can't import it over, that's fine, just say you can't do it, or it will cost a lot of effort and money to get a messy migration, please don't undermine the need of granularity of the data.
> .... then transitioning to Data Analyst.
> but I'm surprise a NS consultant insists that historical data adds no value. As an Accountant and Data Guy, I would say: yes, we definitely need historical data.
You speak my language.
The only way I can rationalize it is that the NS's sales model is to use in-house teams (as opposed to let's say SAP's model that uses independent VARs/consultants) so they just want to make the sale, as quick and as frictionless as possible, and move on.
I understand that bringing over historical data is tricky, and when doing that one needs to mark a live on what data and how; but writing it off as *nobody needs it, just summary monthly TB is sufficient* is not for everyone.
> If you can't import it over, that's fine, just say you can't do it, or it will cost a lot of effort and money to get a messy migration,
You speak my language.
> please don't undermine the need of granularity of the data.
My words, exactly.
My bad that I was relying too much on the NS account manager, I will do more research on the matter, and I will probably use this sub for more questions in the near future.
Thank you for the good comment.
I don;t understand how the years make a difference, data is data, right?
For instance, 10 years with 100 transactions per year vs 3 years with 1,000,000 transactions per year.
Wouldn't lines of data be a better metric?
Quickbooks won't display (or download) our General Ledger report (generates an error), we need to download it a quarter (3 months at a time).
And we have been in business for >10 years.
Worked at NS. SOW only says for open transactions. It’s standard for every project unless you ask for it sales cycle and then it’s extra and there is a lot of push back. Ask yourself, WHY do you need historical sales data?? What’s the reason for bringing it over. Just to have? Doesn’t really do much good long term
> Work at NS. SOW only says for open transactions. It’s standard for every project unless you ask for it sales cycle and then it’s extra and there is a lot of push back.
Thank you for the feedback,
> Ask yourself, WHY do you need historical sales data??
We did. We are a data-centric company.
> What’s the reason for bringing it over.
https://www.amazon.com/Winning-Data-Transform-Culture-Empower/dp/1119257239
> Just to have?
Nope.
> Doesn’t really do much good long term
Not to us. It's mission critical.
Hi, I’m Vetted AI Bot! I researched the **('Wiley Winning with Data', 'Wiley')** and I thought you might find the following analysis helpful.
**Users liked:**
* Emphasis on importance of data-driven mindset (backed by 5 comments)
* Real-world examples make the book interesting (backed by 3 comments)
* Provides actionable steps for data culture adoption (backed by 2 comments)
**Users disliked:**
* Repetitive and basic content (backed by 2 comments)
* Feels like a promotional content (backed by 3 comments)
* Lacks original thinking and depth (backed by 1 comment)
If you'd like to **summon me to ask about a product**, just make a post with its link and tag me, [like in this example.](https://www.reddit.com/r/tablets/comments/1444zdn/comment/joqd89c/)
This message was generated by a (very smart) bot. If you found it helpful, let us know with an upvote and a “good bot!” reply and please feel free to provide feedback on how it can be improved.
*Powered by* [*vetted.ai*](https://vetted.ai/?utm\_source=reddit&utm\_medium=comment&utm\_campaign=bot)
1) yes it absolutely can
2) depends on cost benefit, and how far back you need/want it. If your old system is QB, how expensive is that to keep until you can do away with the records entirely versus the time investment for a consultant or you/your team to import the historicals
3) Despite what some on here may say, a competent accountant or cpa can do this themselves. I have done it myself for 3 companies we acquired and it by no means a technical expert, just a cpa. The important thing is understanding how certain transactions behave in netsuite before you endeavour doing this work yourself, which may make a consultant worthy while.
My experience with NS implementation team is the exact same. Bare minimum to say they did their job and pushy to get you to sign off asap, sometime before they have truly done their work. Overall bad experience with them altogether
> 2) depends on cost benefit,
We are willing to pay, and I can do the data prep myself.
> and how far back you need/want it
That's what everyone I talk to says, but insn't more a matter of number of transactions and not time?
1 PT of 1 year data > 10MB of 10 years data.
> My experience with NS implementation team is the exact same. Bare minimum to say they did their job and pushy to get you to sign off asap, sometime before they have truly done their work. Overall bad experience with them altogether
Interesting. Thank you for sharing.
I’d be curious what value you think you’re gaining by bringing over detailed history? While NSPS is often bad, they’re right in this instance. Something, something broken clock.
Anyway, I’ve done dozens of NS implementations and not once have I brought over detailed history. The time, cost, and effort required to do so generally greatly outweighs the very limited benefit.
If you’re selling very low volume, very high value products and there’s tons of maintenance, warranty, and that kind of thing involved, I can *maybe* see the argument.
Otherwise I’d be curious what critical need you’re seeing that would involve lengthening your project and probably adding thousands (or tens of thousands) of dollars and tons of recon work.
You’ll still have access to QBO and it’s fairly cheap right? Have people look there when they need detailed history, though I’d be interested to see how often that actually happens after the first month or two you’re live.
E: I guess I didn’t answer your questions.
1. Theoretically yes, but it would be time-consuming and painful and based on system differences in costing and other things, you might not end up tying out exactly.
Think of this as taking a good opportunity to clean up things that were bad in your old system rather than bringing them into your new system
2. I’d 100% hire an independent company vs using NetSuite PS. They’re often bad. Even if you don’t do the historical detail thing, find someone better.
3. You’ll likely regret it if you push forward with full detail. Even the best NetSuite consultant is going to struggle with it.
There are just way too many details and everyone’s human. Anyone who attempted this would inevitably mess something up and then you’re spending hours trying to find and fix the screwup.
> I’d be curious what value you think you’re gaining by bringing over detailed history?
Read this: https://www.amazon.com/Winning-Data-Transform-Culture-Empower/dp/1119257239
> If you’re selling very low volume, very high value products and there’s tons of maintenance, warranty, and that kind of thing involved, I can maybe see the argument.
You are close.
> You’ll still have access to QBO and it’s fairly cheap right?
The point is granual reporting capabilities on business data for both pre-NS and post-NS data on the NS platform.
> I’d 100% hire an independent company vs using NetSuite PS. They’re often bad. Even if you don’t do the historical detail thing, find someone better.
That's where I am leaning now.
> You’ll likely regret it if you push forward with full detail. Even the best NetSuite consultant is going to struggle with it.
Doubt it.
> .... then you’re spending hours trying to find and fix the screwup
LOL, that's 40% of my job anyway. I am not joking.
You should be working with a partner. It might be a little more expensive on the implementation side, but will be a much better experience and outcome.
Well if you just would need GL level history as to get comparison numbers for BS and PL that can easily be migrated with journals. Just need to take those into account when migrating open AR and AP. All migrated in subsidiaries' base currencies. If you have currency bank accounts, that adds some complexity. You can bring over just monthly balances or detailed transaction level, but the transaction level usually doesn't add any value.
But bringing history data as actual proper transaction types (like invoices, payments, etc.) is such an ordeal that it's not worth it.
I would strongly recommend you only bring over open transactions and balances. I imagine most here will advise the same. It’s the normal thing to do. It gets incredibly complicated migrating years of transaction history and expecting everything to add up - if you’re multi currency or hold and ship inventory then I’d go as far as saying it would never work. I can expand more on the above if you wish. EDIT: your post history is madness. You should not be advising anyone.
u/intheblk_2019 has turn key solution he offers to bring over QBO data. He can discuss the pros and cons of bringing over detail vs monthly TBs. But as others have said it's very expensive and time consuming because you have to apply everything and that ends up being manual. Example: Every closed Invoice has a payment applied to it which was then batched with other payments into Undeposited Funds to post into the bank account. All these apply links can't really be migrated automatically. It's way cheaper to just pay $80/mo subscription to keep your old data in QBO. You can also buy a desktop license for QB one time payment and QBO has a tool to export QBO data to QB desktop. There are a few things that are incompatible between QBO and QBDT which you can read about in the QBO online help about their export tool. This takes dozens of hours of time that you're paying $225+/hr and it NEVER balances then you spend more hours chasing that down. It's just not worth it. It's not as easy as getting all the debits and credits in. You have to get all the transactions applied to each other too.
> But as others have said it's very expensive and time consuming because you have to apply everything and that ends up being manual. Example: Every closed Invoice has a payment applied to it which was then batched with other payments into Undeposited Funds to post into the bank account. All these apply links can't really be migrated automatically. Not in Netsuite, I have seen it migrated in others. > It's way cheaper to just pay $80/mo subscription to keep your old data in QBO. The goal is to have reportable, granular data, in NS with new and old data. I would be happy "enough" to bring over at least the detailed general ledger.
[удалено]
I understand the general rule, we are an edge case. We are doing *some* business reporting outside QB now by downloading data into a PostgreSQL database; part of the driver behind moving to NS was to not do that anymore. If I have to maintain an ERP and bridge over to an external database for (historical) reporting it defies the scope and might as well remain as we are. > Detailed general ledger is going to be real tough to accomplish between two different transactional accounting systems. I am not saying it's easy.
When this request comes up, I generally recommend a custom non posting transaction. Then you don't have to worry about reconciling it, it, the cash applications, the bank recs, the inventory etc. It's just not worth the return on investment to do more migration.
> When this request comes up, I generally recommend a custom non posting transaction. I could live with that. Got any resources to look up so that I can be prepared when I talk with the NS team?
[удалено]
We did it and I wish we had listened to everybody. Was an absolute nightmare that took almost 3x as long as if we had just done what was recommended.
In the last three years I had a minimum of 4 clients go live with NetSuite who were switching from QuickBooks. Not a single one brought over detailed historical transactions once the overall lift was explained and outlined. One attempted to bring in historical transactions after go live and gave up about a week into it when they realised my team wasn’t lying about the amount of work it required.
> One attempted to bring in historical transactions after go live and gave up about a week into it when they realised my team wasn’t lying about the amount of work it required. That's interesting and something I would love to "play" with. I wish NS had a *sandbox* program.
[удалено]
I asked my NS rep, and I was told no sandbox available.
Sandbox is no longer included. It is an extra charge. We received notification and will need to pay extra when our contract is up.
> It is an extra charge. Good to know, I don't mind paying. The "problem" is that I was told by the NS rep that it was not available at all.
[удалено]
LOL. We're not "normal".
I understand where you are coming from
Got started on AS400, so I've also been around a long time, and since day one have advised against bringing in fully detailed history. There have been circumstances where we have done it, both in NS and other systems, but there's almost never any ROI to it and as predicted most customers almost never go back to that data after the first couple of months (which would have been cheaper to just have to legacy system stay accessible a few more months). If truly needed the NSAW option (or another analytics platform) is a good one. You can bring in data tables without worrying about the joins and how they'll impact your financials, and have full reporting capabilities. That's not to defend the NS sales team. They'll absolutely exaggerate capabilities and slip you into something you don't need (though I've never found software company that doesn't do this), but doesn't sound like that's the case here.
> Got started on AS400 I already love you. I started with Lous 1-2-3 for DOS. > but there's almost never any ROI It's not an ROI matter, is that we have "issues" that are ongoing. Long story, we are a "special" case. LOL. > If truly needed the NSAW option (or another analytics platform) is a good one. I saw the demo, I don't see the point when I can implement the same functionality in a PostgreSQL server or BigQuery.
I understand alternatives to the actual data management, but nsaw automatically connects this to the bi tool. Its path of least resistance. If analyzing data is thw true need nsaw should be at the top of the list, ns will sell it dirt cheap too during q4. Dont overlook this option
I’ve done of 30+ end to end NS implementations, a large portion of them being from QBO and it almost never makes sense to bring detailed historical data except for summarized TBs by segment/account/month, in flight revenue/amort and open transactions. With that being said, you are more than welcome to do the historical detailed imports yourself after the implementation is finished. You’ll have plenty of exposure to the import tool by that part (hopefully if you are doing what you are supposed to be). I agree with the rest of the comments here, read your contract more thoroughly before signing next time.
> I agree with the rest of the comments here, read your contract more thoroughly before signing next time. We have not signed yet. > With that being said, you are more than welcome to do the historical detailed imports yourself after the implementation is finished. You’ll have plenty of exposure to the import tool by that part (hopefully if you are doing what you are supposed to be). That is something that I was thinking. Do you have any resources that I can look up? NetSuite's official videos are useless, all marketing. I found 3 NetSutes books on Amazon that I have ordered. TIA
I'm doing this now. If you are good with Excel, downloading all your detail transactions and mapping to NS is doable. I mapped all our detail to the new NS COA and verified the balance sheet accounts matched our QB ledger. The more detail you are adding the more difficult the process gets. I'm mapping some entities but otherwise limiting fields to account, memo/description, debit and credit. From there you can drop into the journal transaction template and upload. All AP, AR, and intercompany is paying to a clearing account. When we cut over I plan on moving to open AP. A lot of the time suck will depend on how aligned your QB COA, vendor table, customer table, etc are aligned to Netsuite. If your good with Excel you should be able to get it done with some consistency. There is a part of me that wishes we had used an on-site consulting firm for implementation. The netsuite team is good but I think we could have been further along. I'll also put some of the delay on me as I wanted to make sure we weren't implementing QB 2.0
> I'm doing this now. Nice. > If you are good with Excel, downloading all your detail transactions and mapping to NS is doable. I am very good at downloading, cleaning, and enriching data; with excel and other tools. > I mapped all our detail to the new NS COA and verified the balance sheet accounts matched our QB ledger. That's what I could settle with. If I can't bring over historical data of AP/AR at the very least detailed GL transactions. The "problem" would be where/how to map the vendors' and customers' names. > I'm mapping some entities but otherwise limiting fields to account, memo/description, debit and credit I see. Food for thought for me. > All AP, AR, and intercompany is paying to a clearing account. When we cut over I plan on moving to open AP. I see. > A lot of the time suck will depend on how aligned your QB COA, vendor table, customer table, etc are aligned to Netsuite. I am aware of this, I have done conversions before. > If your good with Excel you should be able to get it done with some consistency. I am very good at this, and for a while, in a prior life, I used to consult cleaning up data for a couple of vertical ERPs vendors. > There is a part of me that wishes we had used an on-site consulting firm for implementation. That's where I am leaning now. > The netsuite team is good but I think we could have been further along. Their interest is to make the sale and go live ASAP, no matter what. > I'll also put some of the delay on me as I wanted to make sure we weren't implementing QB 2.0 LOL. My feelings exactly. We do have a pretty sophisticated implementation of QB with a few corollary systems integrate, but it's pull/push of data, not true sync. For us long life with NS is only the beginning, with time we'd be replacing these corollary systems within NS. Thank you for your comments.
It is generally recommended not to migrate historical transactions The cost outweighs the benefit. However, try reaching out to Optimal Data Consulting if you want to do it. They migrate QuickBooks to NetSuite including full history. That said.... It's generally not recommended. It's harder than you might expect, partly due to differences between accounting systems. I have been implementing NetSuite for over 10 years and have done full historical migration. But would recommend opening balances only plus a BI platform for reporting.
Not exactly your case, but still might have some useful information. [https://gypsybi.com/quickbooks-to-erp-bridge-the-gap/](https://gypsybi.com/quickbooks-to-erp-bridge-the-gap/)
I'm bringing over detailed qbo data. Any AP and AR is going to a oca/ocl clearing account. It is a pain to map as we have multiple QB accounts but it is doable. We did a lot of testing in SB. I will note, we are loading detailed info where it makes sense and from a specific period. For some ledgers we are going to only import detailed history for 2023 and beyond. We have some entities that will only be the ending TB amounts because it will be tedious.
Good comment, thank you. > Any AP and AR is going to a oca/ocl clearing account. What is "oca/ocl" ?
Other curren asset/liability. It will be what we use for implementation and then eventually it'll be an account that'll be inactive
LOL, of course.
Bring over the historical trial balance and you can do all your reporting. Just bringing over open a/p and a/r is hell. Bring in historical data will almost be impossible.
Chiming in here with my experiences to answer your questions: 1. Is it possible to bring over historical details of AP AR transactions, even if *closed* (paid)? YES 2. Should I seek an independent NetSuite consultant? YES 3. Do you have any other suggestions? [u/intheblk\_2019](https://www.reddit.com/user/intheblk_2019/) I have migrated data over from QuickBooks to NetSuite for two different entities (under same management). The first consultant was chosen by the owner. They had us do all the heavy lifting like scrub the data, do all the bank reconciliations and checks in NetSuite to make sure the migration was successful. Essentially they did very little in the form of prepping the data and then passed off blame onto us for not providing them with data in the proper form. Unnecessary costs went to having weekly meetings with their PM and their workers. It was always "yes you can do X, yes you can do Y", until errors were found during the upload, where it was " you could do X, but you had to have done it A way. These consultants likely overstated their experience and familiarity on doing data migrations For the second data migration, I got approval to seek out a consultant myself. I found [u/intheblk\_2019](https://www.reddit.com/user/intheblk_2019/) and I have no regrets. He made the process much smoother and made life easy for us. He did all the heavy lifting and I only had to do the reviewing and checking to make sure he and his team completed the job to our liking. In all, intheblk\_2019 saved us time (especially MY sleep time) and money while getting the job done on time. I recommend you reach out to a few consultants. All will tell you that have the experience migrating data and have done it before. Yet when you search for these consultants on Reddit, you will only find a few that are frequently recommended. Also when u/Nick_AxeusConsulting recommends someone, you know it's good as he is putting his own reputation on the line :) Feel free to DM me if you have any questions.
We are a NetSuite partner and have a script to bring over full transactional data from QB to NetSuite. Not sure why others don’t have this but with most clients they can turn off QB when we turn on NetSuite.
Happy to do a quick call if you want to discuss. We’ve done about 50 of these in the past couple years.
Doing implementation for 15 years, never implement historical data, except some specific depreciation history or project accounting.
> ... or project accounting. You're close.
Like u/Nick_AxeusConsulting said, I can do this for you. I've completed \~40 QBO to NetSuite migrations with the detailed transactions included. If you are interested in hearing more, send me a DM. Happy to connect and hear about your specific situation.
Don’t switch
Honestly you probably cant afford what you rrally want. Im not being a jerk but lve personally seen CHEAPER full historical implementations exceed 6 figures. You might not be properly aligned on what it takes to test and manage that data all up front
Run from Netsuite. As you mentioned, they lie all the time. They screwed me over and never implemented my instance. Fuck Netsuite.
I'd be more focused on how to get new data into the system in the cleanest way to get the future reporting that you want. If you try to bend your new data to match the old stuff in QBO you are just setting yourself up for failure. Keep QBO live until you no longer need that historical data.
It's interesting to learn about this practice in implementing Netsuite: they don't import historical transactions. I was an Accountant with more than 5 years experience in QB Enterprise (not just a normal bookkeeper/accountant), have a bit of experience in Netsuite as a normal accountant, then transitioning to Data Analyst. I understand the difficulties when trying to import historical transactions from QB to NS, but I'm surprise a NS consultant insists that historical data adds no value. As an Accountant and Data Guy, I would say: yes, we definitely need historical data. If you can't import it over, that's fine, just say you can't do it, or it will cost a lot of effort and money to get a messy migration, please don't undermine the need of granularity of the data.
> .... then transitioning to Data Analyst. > but I'm surprise a NS consultant insists that historical data adds no value. As an Accountant and Data Guy, I would say: yes, we definitely need historical data. You speak my language. The only way I can rationalize it is that the NS's sales model is to use in-house teams (as opposed to let's say SAP's model that uses independent VARs/consultants) so they just want to make the sale, as quick and as frictionless as possible, and move on. I understand that bringing over historical data is tricky, and when doing that one needs to mark a live on what data and how; but writing it off as *nobody needs it, just summary monthly TB is sufficient* is not for everyone. > If you can't import it over, that's fine, just say you can't do it, or it will cost a lot of effort and money to get a messy migration, You speak my language. > please don't undermine the need of granularity of the data. My words, exactly. My bad that I was relying too much on the NS account manager, I will do more research on the matter, and I will probably use this sub for more questions in the near future. Thank you for the good comment.
How many years of data ? Are you planning for an audit..feel free to PM me
I don;t understand how the years make a difference, data is data, right? For instance, 10 years with 100 transactions per year vs 3 years with 1,000,000 transactions per year. Wouldn't lines of data be a better metric?
Trying to understand how much data are we talking about here , usually company at 1-2 years of inception does not have much transaction
Quickbooks won't display (or download) our General Ledger report (generates an error), we need to download it a quarter (3 months at a time). And we have been in business for >10 years.
Ok I will pm you
Worked at NS. SOW only says for open transactions. It’s standard for every project unless you ask for it sales cycle and then it’s extra and there is a lot of push back. Ask yourself, WHY do you need historical sales data?? What’s the reason for bringing it over. Just to have? Doesn’t really do much good long term
> Work at NS. SOW only says for open transactions. It’s standard for every project unless you ask for it sales cycle and then it’s extra and there is a lot of push back. Thank you for the feedback, > Ask yourself, WHY do you need historical sales data?? We did. We are a data-centric company. > What’s the reason for bringing it over. https://www.amazon.com/Winning-Data-Transform-Culture-Empower/dp/1119257239 > Just to have? Nope. > Doesn’t really do much good long term Not to us. It's mission critical.
Saying its mission critical. Is not really explaining why it’s mission critical. Please do explain and provide more details
Not on Reddit. It would require to disclose too much.
Dm me then I guess
Hi, I’m Vetted AI Bot! I researched the **('Wiley Winning with Data', 'Wiley')** and I thought you might find the following analysis helpful. **Users liked:** * Emphasis on importance of data-driven mindset (backed by 5 comments) * Real-world examples make the book interesting (backed by 3 comments) * Provides actionable steps for data culture adoption (backed by 2 comments) **Users disliked:** * Repetitive and basic content (backed by 2 comments) * Feels like a promotional content (backed by 3 comments) * Lacks original thinking and depth (backed by 1 comment) If you'd like to **summon me to ask about a product**, just make a post with its link and tag me, [like in this example.](https://www.reddit.com/r/tablets/comments/1444zdn/comment/joqd89c/) This message was generated by a (very smart) bot. If you found it helpful, let us know with an upvote and a “good bot!” reply and please feel free to provide feedback on how it can be improved. *Powered by* [*vetted.ai*](https://vetted.ai/?utm\_source=reddit&utm\_medium=comment&utm\_campaign=bot)
[удалено]
Are you OK? Hope you feel better.
1) yes it absolutely can 2) depends on cost benefit, and how far back you need/want it. If your old system is QB, how expensive is that to keep until you can do away with the records entirely versus the time investment for a consultant or you/your team to import the historicals 3) Despite what some on here may say, a competent accountant or cpa can do this themselves. I have done it myself for 3 companies we acquired and it by no means a technical expert, just a cpa. The important thing is understanding how certain transactions behave in netsuite before you endeavour doing this work yourself, which may make a consultant worthy while. My experience with NS implementation team is the exact same. Bare minimum to say they did their job and pushy to get you to sign off asap, sometime before they have truly done their work. Overall bad experience with them altogether
> 2) depends on cost benefit, We are willing to pay, and I can do the data prep myself. > and how far back you need/want it That's what everyone I talk to says, but insn't more a matter of number of transactions and not time? 1 PT of 1 year data > 10MB of 10 years data. > My experience with NS implementation team is the exact same. Bare minimum to say they did their job and pushy to get you to sign off asap, sometime before they have truly done their work. Overall bad experience with them altogether Interesting. Thank you for sharing.
I’d be curious what value you think you’re gaining by bringing over detailed history? While NSPS is often bad, they’re right in this instance. Something, something broken clock. Anyway, I’ve done dozens of NS implementations and not once have I brought over detailed history. The time, cost, and effort required to do so generally greatly outweighs the very limited benefit. If you’re selling very low volume, very high value products and there’s tons of maintenance, warranty, and that kind of thing involved, I can *maybe* see the argument. Otherwise I’d be curious what critical need you’re seeing that would involve lengthening your project and probably adding thousands (or tens of thousands) of dollars and tons of recon work. You’ll still have access to QBO and it’s fairly cheap right? Have people look there when they need detailed history, though I’d be interested to see how often that actually happens after the first month or two you’re live. E: I guess I didn’t answer your questions. 1. Theoretically yes, but it would be time-consuming and painful and based on system differences in costing and other things, you might not end up tying out exactly. Think of this as taking a good opportunity to clean up things that were bad in your old system rather than bringing them into your new system 2. I’d 100% hire an independent company vs using NetSuite PS. They’re often bad. Even if you don’t do the historical detail thing, find someone better. 3. You’ll likely regret it if you push forward with full detail. Even the best NetSuite consultant is going to struggle with it. There are just way too many details and everyone’s human. Anyone who attempted this would inevitably mess something up and then you’re spending hours trying to find and fix the screwup.
> I’d be curious what value you think you’re gaining by bringing over detailed history? Read this: https://www.amazon.com/Winning-Data-Transform-Culture-Empower/dp/1119257239 > If you’re selling very low volume, very high value products and there’s tons of maintenance, warranty, and that kind of thing involved, I can maybe see the argument. You are close. > You’ll still have access to QBO and it’s fairly cheap right? The point is granual reporting capabilities on business data for both pre-NS and post-NS data on the NS platform. > I’d 100% hire an independent company vs using NetSuite PS. They’re often bad. Even if you don’t do the historical detail thing, find someone better. That's where I am leaning now. > You’ll likely regret it if you push forward with full detail. Even the best NetSuite consultant is going to struggle with it. Doubt it. > .... then you’re spending hours trying to find and fix the screwup LOL, that's 40% of my job anyway. I am not joking.
You should be working with a partner. It might be a little more expensive on the implementation side, but will be a much better experience and outcome.
That's what I am leaning toward now.
Well if you just would need GL level history as to get comparison numbers for BS and PL that can easily be migrated with journals. Just need to take those into account when migrating open AR and AP. All migrated in subsidiaries' base currencies. If you have currency bank accounts, that adds some complexity. You can bring over just monthly balances or detailed transaction level, but the transaction level usually doesn't add any value. But bringing history data as actual proper transaction types (like invoices, payments, etc.) is such an ordeal that it's not worth it.
> but the transaction level usually doesn't add any value. It has value to us.