Upgrading in countries with "Eastern Europe Feature Pack"

herrlutz

Hello experts,

we have separate NAV3.70B installations in CZ,HU,PL,UA,RU and want to upgrade them to NAV2009 R2.
Unfortunately it seems that there is no direct upgrade toolkit for countries with Eastern Europe Feature Pack from 3.70B --> NAV2009 R2

Instead, it´s necessary to upgrade like 3.70B --> 4.0 --> 5.0 --> NAV2009, but different from country to country as the NAV localization comes even on top of the Eastern Europe Feature Pack.
This approach would mean a big effort for us, as we would have to do that for each country and have a separate partner in each country.

What i´m looking for is someone who has the same problem and/or experiences for best practise.
What i´m thinking of is to develop an upgrade tookit for Eastern Europe countries in one step and an approach to consider the country specific differences. maybe this is useful for other customers as well and we might share the efforts on that.

please contact me with any ideas

rhpnt

herrlutz wrote:

What i´m thinking of is to develop an upgrade tookit for Eastern Europe countries in one step and an approach to consider the country specific differences.

I don't think this is possible. Since every EE country (although some are already in the EU) kept parts of its local legislative (especially taxation) and other "goodies", it will be near impossible to upgrade all with one methodology. Why even bother developing an upgrade tool when MS provides all resources for a successful upgrade? True, you have to do it by version and it's a lot of work, but there sure is some good reason for that.

herrlutz

we have a lot of adjustments in our W1- database template.
For each country we would practically need one merged, localized object set for version 4.0, 5.0, 5.0 SP1 incl. EE Feature Pack and for 2009 SP1 R2. For each sub- version i think it needs some days to merge, even if "in between versions" just need to be capable to be compiled. so for each country there will be a Big workload for the whole task. It´s difficult to justify these costs, as they mainly appear just because there is no direct upgrade toolkit 3.70 --> 2009 SP1 R2 in EE.

Additionally it might become runtime critical to go version by version. In Western hemisphere there is an official upgrade toolkit from 3.70 to 2009 SP 1 which takes nearly one weekend to run in our databases at average. No idea how long it would take to run "Upgrade Toolkit Step 1", Import Objects, "Upgrade Toolkits Step 2" version by version like described above for EE. We can´t effort to have downtimes in our core business.

Further, we have a separate partner in each country, This means to purchase the same kind of services as described above country by country. There is no lessons learned from country to country in that approach, and we have to invest again the full amount in the development of the country individual migration tools.

I wonder if there are partners who have experiences in several Eastern Europe Country at all??

I think the upgrade path for eastern europe provided by Microsoft is not practical at presence. Our Czech partner told us, that in practise instead of migrating with upgrade toolkits, their clients just start in the new version with a blank database incl. data transfers for master data but without history data. So I wonder if EE partners have experiences in multi version upgrades at all, and if not it will be a risk.

In my opinion Microsoft should urgently provide an upgrade toolkit 3.70/4.0 to 2009 SP1 R2 as part of the maintenance fee the customers pay, as it´s in practise not realistic for multi site customers to have always the newest release rolled out. But this is probably a different audience to discuss...

For now, ideas or partners thinking they can help us are welcome!

David_Singleton

herrlutz wrote:

Further, we have a separate partner in each country, and i wonder if there are partners who have experiences in several Eastern Europe Country at all. Having separate partners in these countries means to begin to purchase the same kind of services as described above country by country, and just because there is no official upgrade toolkit from 3.70 to 2009 in one step. There is no lessons learned from country to country in that approach, and we have to invest again the full amount in the development of the country individual migration tools.

My approach to this would be first to assign one person as global project manager. have that person put together a draft outline for upgrading and send it to each of the partners you have in the individual countries. Then have them send their comments on why it wont work. Review these issues and throw out the nonsense reasons. Then once you have a complete list do a for against analysis of upgrading vs starting clean. When you have that, send that person for a couple of days to each of the countries to discuss specifically with each manager (with the country partner coming in for one day as well) what their issues would be using both approaches. By this time you should have a clear picture of what is needed. Then bring everyone together for a 2 day seminar and have it all out and decide what makes sense.

Although the cost of all this may seem wasted, the reason you do it is to give every one a chance to air their thoughts, and thus leave no question when eventually you go live for one person to throw a spanner in and ruin the project.

remember also that a jump this big may mean that a lot of new features in the base product are not being used, so starting clean may have many advantages to your business above simply reducing the complexity of upgrading. Its possible that many of the customizations can just be thrown out.

Another thing to keep in mind, is that there are many companies in Czech Poland Hungary etc that run their business on a W1 base. I know they whine and complain about "Oh our laws are soooo complex you just wouldn't understand it ..." but most of that is just BS so that they can feel special. I most cases it is much easier in an environment like this to run everyone on the same W1 code base and have parametrized configurations custom made for their little quirks.

And this is coming from the person that implemented the first official Navision systems in CZ, PL and HU. :whistle:

herrlutz

Thank you for that David, I can really breathe your experience :-)
In fact this will be the approach as we will do it from a methodology perspective.
And maybe you're right and the only realistic path for us to go is by starting "clean" and forget the upgrade toolkits. But this can be evaluated carefully in the way you describe.

but also starting clean is not the way we like, as we pay maintenance fee to Microsoft which should save our investment for future, and starting "clean" feels more like introducing a new ERP rather than just upgrading.

Hence... if someone did already merge the several version upgrade toolkits for one/ some EE country or has successfully done an upgrade project in EE from 3.70 or 4.0 to 2009 it would be great to hear about your experiences!!

David_Singleton

herrlutz wrote:

Thank you for that David, I can really breathe your experience :-)
In fact this will be the approach as we will do it from a methodology perspective.
And maybe you're right and the only realistic path for us to go is by starting "clean" and forget the upgrade toolkits. But this can be evaluated carefully in the way you describe.

but also starting clean is not the way we like, as we pay maintenance fee to Microsoft which should save our investment for future, and starting "clean" feels more like introducing a new ERP rather than just upgrading.

I totally agree that there is a feeling of not getting what you pay for. But in the end your business needs are the prime concern, and thus you should analyze both approaches and decide which is best for business. Maybe also looking at a strategy that next time will allow you to better utilize the upgrade path, i.e. by having all countries on a common code base and minimizing the number of customizations.

But I think that without consultation and buy in from all parties it can be very difficult. I have seen cases where someone felt that the decision was forced on them without being involved in that decision, and they resent that. Which is why I suggest the approach of first addressing each country individually and then inviting them all to come together to be apart of the global decision. It so much easier to implement something like this when the parties want it to happen.

David_Singleton

rhpnt wrote:

I don't think this is possible. Since every EE country (although some are already in the EU) kept parts of its local legislative (especially taxation) and other "goodies",

I used to hear this a lot. But how true is it really. There are some extremely minor issues that are different; rounding of VAT; Job accrual posting; G/L Account sorting; Fixed asset depreciation rules; but most of these can be handled with very minor customizations, and most times they don't even affect the company that feels they need these customizations.

In general when you have an implementation covering many countries why not run W1 with the appropriate language pack?

herrlutz

David Singleton wrote:

rhpnt wrote:

I don't think this is possible. Since every EE country (although some are already in the EU) kept parts of its local legislative (especially taxation) and other "goodies",

I used to hear this a lot. But how true is it really. There are some extremely minor issues that are different; rounding of VAT; Job accrual posting; G/L Account sorting; Fixed asset depreciation rules; but most of these can be handled with very minor customizations, and most times they don't even affect the company that feels they need these customizations.

In general when you have an implementation covering many countries why not run W1 with the appropriate language pack?

It´s the old discussion of running several countries in one database, which is an important discussion when talking about the international capability of using NAV. Running several countries in one database means significant advantages in object administration, but also leaving the offical path of Microsoft.

After 10 years international NAV experience my personal clou is, that it´s possible to run western hemisphere countries in one database on W1 basis. In these countries, the country individual gaps will be more or less the A/R Mangement (Customer "statements" in UK, AU, SA etc.), the VAT reports (XML schemes), electronic banking, EU- Intrastat and Environment reports. France is a critical exception in that western hemisphere due to letter of credit function. I dont know about Italy, but I've heard it might be too complex to renounce on the localization.
My personal positive list for a W1 western database could be Dk, No, Se, Uk, Au, DACH, Be, NL. I hope that Microsoft one day will pick up this kind of thinking.

For eastern Europe i recommend to avoid running several countries in one database, as the country specific differences might be too significant:
- CZ: this country has very western based economic rules, and i don´t see why Microsoft decided to introduce the Eastern Europe Feature Pack here. Therefore, CZ can better be put on a "W1 Western database" like written before
- HU, PL: here there are "Correction Invoices" instead of Credit Notes for Purchase and Sales as well as the "VAT Settlement Date" in all documents. Further in PL there is a critical "Unit Price incl. Discount" on Sales Lines with a complex rounding behind.
- RU: this is completely separate from W1 due to "G/L Correspondence Ledger Entries", "CD Number" on Sales Invoices, cancellation of debit/credit amounts in all types of Ledger entries for credit notes, several "AKTs", complex Fixed Asset Accounting and VAT reports are done based on a complex setup in Navision and finally exported to excel.
- UA: russian complexity multiplied by 1000 due to "First Event VAT" and millions of restrictions and formal acts, no official Microsoft localization, but only partner solutions.

But why not try to merge the several "in between version" of the eastern europe upgrade toolkits into one toolkit per country?
This might be a realistic alternative approach to either start "clean" or merge and upgrade version by version.