For these purposes every Partner has prepared a set of DataPorts as well as policy in general how to start a company in NAV, as majority of Clients have already a history to import - almost noone starts using NAV from the first days of operation.
Detailed info is too large to be posted here, but in general these are DataPorts with some validation code, filling Startup Journals, which are then posted to be sure all supplemental tables – not only Ledgers/Cards – are appropriately updated.
is possible, but rarely practiced, as this is a HUGE job to prepare these data in importable format.
Document history means changes points 1) and 2) - then you must import data not as of “kick-off” date, but ALL previous years of operation in detail. Normally nobody does it - amounts (and expenses !) are tremendous, and that doesn’t pay off - its easier/quickier to look up these data in old system, besides need for such lookups is rare.
General practice for 3 and 4 would be not to do it. The balance of value against cost is never worth it in my opinion. I have only had one customer demand it, it cost them an awful lot, I cannot say if they went live as I left the company before it happened, but I can say it was not worth the investment in my opinion, and they would probably admit this now.
For 1 with NAV we treated each case differently and moulded the dataport to the file, in AX we have set procedures and formats and make the customer get it in that format.
For 2 each case is different again, yes you have the item number, quantity, cost and warehouse, but you may have bins, batches etc, but again it is a recycling of dataports to meet the needs of the file.
I highly appreciate Your practical experience, … but … as beginner here I can not give-up in first set [:)].
More than 10 years I have been in side of customer as something like process owner (I was a management accountant) during implementation of some ERP systems (not NAV). Our business was producing/selling of SLOW moving items - so in point of going live with ERP N+1, there was a lot of stock produced (“costed”) in ERP N. And because items were slow-moving in general, a long time in ERP N+1 was necessary to see both - new and old (migrated) stock in one report.
Additionally we used to do lot of profitability-compare reporting - so Your argument “… 3 and 4 is huge job - look old data in old system” would be out of discussion.
OK - it was in old fat times, when figures of previous year said something valuable
Immagine that this client has decided for ERP N+2=NAV and is ready to serve any data from their N+1 SQL database in any format detailed enough for his reporting needs (and accidentally for NAV table-structure-specific needs too) :-).
Would You as independent 3rd-party expert in such case still say that “it does not pay off” or swich on plan “B” for migration case #3?
Please, if any of the replies to your post solved your problem, then please click on the “Verify solution” next to that post. This way we can see that your post is closed and you got the help you needed. If you found another solution to your problem, then please, out of courtisy to the members who helped you here, post the solution here.
please understand me right. I did not forget about “Verify solution” button, but … I am still waiting something more. Comments of Modris and Adam were really helpful to understand that :
smart partners know how to do this,
it is lot of work,
but I think that green chekmark would be misleading for all who want to use this topic to learn how to do migration.
From commercial point of view may be there are situations when client and consultant agree that solution under question is too expensive, but I believe that we are here to look on Navision also from “scientific” point of view . Are not?
I thing yellow chekmark would be better for this topic at this moment, but it seems I can not “Sugest solution” in topic initiated by myself
I think its extremely rare that I would disagree with Steven, (in fact I think this is only the second time [:O] in about 10 years), but to the value of history I must disagree at this point with the remarks of Steven and Modris.
I beleive EVERY customer needs to bring history across, the question is how much history, meaning how far back and how much detail. And in this factor ever client is different.
For many businesses, the value of the historical data is huge, for some it is not important. And this needs to be measured in monetary terms. Customers that sell seasonaly cyclic products may live or die on the knowledge of what items they sell each June and the trends over the past five years. Some companies have finanial reporting requirements that mean they need 3 years of history. There are customers that have very extended terms, and may have AR stretching out to 180 or even 365 days on big projects, lack of documentation for that may mean disputed payments costing the business a lot of money. (And there are hundreds more expamples) these companies need to value the cost of importing the history vs the cost of maintaining two systems, and then consolidating the two. Many companies are moving from antiquated and unsupported systems, and thus don’t even have the option of refering to their old system once it is shut down.
I have had to come in to clients to recover lost data, i.e. to bring over history that was deemed as unimportant by some consultant at implementation time, and now the client is paralyzed and can not run their business because of some quick words said in a meeting that no one really understood.
IN MY OPINION: "all customers need SOME history, and we need to very carefully evaluate the ROI to determine HOW MUCH history we bring over.
Pretty sure we do not disagree [:D] this was my opinion based upon experience and a value against cost analysis. I am always willing to allow the customer to spend large pots of money if they can justify it to me - perhaps I am a slightly unusual consultant in this respect! However to hear a consultant undervalued the data surely also means the customer did!
Anyway, on the financial front I do find this common, back posting 3 years of information monthly etc, but this is not really a big task, 36 journals with dimensions realigned is generally always worth the cost/value ratio if you can get the data aligned to the new dimension structure.
The issue I have is with trying to reproduce the sales history data as sales history data in NAV. I believe you always need to analyse the “why”. Legally you need to be able to reproduce an invoice “x” years afterwards, so if you are turning off your legacy system do you have hard copies or are you converting data. I have seen system push the legacy data into a separate table to allow periodic one off table reporting, and using SQL reporting services etc this approach becomes easier, even leaving the data where it is an interogating it is an option. It is just the whole effort and cost of replicating posted sales orders consuming inventory, with appropriate costs and payment history is simply MASSIVE - and the customer has to justify it, because EVERY customer states at the outset they need the history, and when you sit down and analyse the data and what they need in most cases you can dramatically cut down the data required - but you have to ask, inerrogate and assess, that is what the consultant is being paid to do afterall [:D]