Multi Country Rollout

amitsobti

Hi ALL,

Can anyone share a sucess story of the multi-site-international organisation rollout...which have multiple localisations on single db.

What approach has been taken for the same..

Pls share your experience.

Thanks,
Amit

matttrax

Our approach was not to do it

Nightmare of an upgrade. Nightmare to maintain. Wasn't worth it to us...and that was only for three countries.

jsrark

We decided not to take this approach.
We do not have a complicated business so the extent of company specific changes was limited and we believed it was easier to move our changes to country specific databases rather than moving country-specific localisations to one database.
Multiple database gives the opportunity to cater for local requirements e.g. statutory reporting, local banking and local payment systems.
We saw risks in sharing data due to different currencies (look at the Item Card, which cost and price are stored on the card) for example.

matttrax

Unless you will see significant savings by moving to one database, which I can't imagine, it's really not worth it. In my opinion anyway.

jannestig

We did it for a particular client who had a big budget and we needed to do so to meet their business model, of one purchasing enties and sales entities for multiple countries.

What i prefered to do was find the "global standard database" ie you develop in W1 with modification that make up the customers requirements to operate in its way.

From there we implement the template with a merge of country requirements max we did was 4 countries for nordic and then individual requirements EG one countires warehouse operates differently from anothers EG daisy chain VS pick to light

Theres is a limit to how much functionality you put in before your head explodes sorting them though,

So it can be done but it should be well planned and well tested

You can reference Gamestop as the biggest i know of

kriki

Some problems you can get with all countries in 1 DB:
-ML-captions are limited to 1024 chars and if you reach that because you too much languages, you need to fix it and it is no so easy
-sometimes, the changes for a country in a function is so extensive as to make it completely incompatible with changes in other countries. In this case that function is best divided into independent functions. And this is difficult too maintain, because if something changes in your core versions, you have to apply it to all those functions anyway.
-If each country has a BIG company, you need 1 BIG server to do all and if the server fails, all countries stop working. If you have 1 DB for each country, you can easily scale out (=put different DB on different servers) the countries and if one server fails, the others continue to work. Multiple smaller servers in general are cheaper than 1 BIG server.
-if upgrading, it is all-or-nothing and you need 1 BIG window to upgrade all. Eg. is it better that all countries are off-line for 1 week to do the upgrade or each country is off-line 1 day for the upgrade (spread over multiple days or even multiple weeks)?

So in short: I am against the idea.

kine

We are using the multi-database approach for our international customers. Main development is done on one central DB (in most cases W1 DB) - there the shared processes common to all the companies are developed. Than they are applied to all local DBs with local changes. As alredy wrote someone else: it is better to update, support and maintain. But it must be correctly processed, there must be clear ways how to do the developments, what should be in the "Shared bubble", what will be in the "local bubble", how the changes from shared bubble are implemented into local bubble etc. (bubble is set of changes for me in this case). There must be clear hierarchy defined to know who is responsible to decide about what etc.