@janneman,
Guys, First: we agree with Carlos Liebana: sometimes you can migrate only some data from one OpenERP to an other OpenERP, this can easily be done with OOOR/TerminatOOOR scripts or an other tech. But this is not suitable to migrate the whole ERP with things like accounting, partial reconciliations etc... (as ids, states will changes...) To achieve full migration, we should indeed migrate the existing database, the schema + the data. Schema evolution is done at 50% by the OpenObject ORM with the --update=all option. Then extra schema changes can be done by modules scripts. @Sharoon, Just like Tryton, OpenERP handles per module migration scripts, this is to be seen here: http://bazaar.launchpad.net/~openerp/openobject-server/trunk/revision/2722 http://bazaar.launchpad.net/~openerp-bpso/bpso.openerp/migration_script_/revision/2741 I didn't test the Kndati migration tool yet. But if it's per module oriented, then that's fine and that could probably be plugged with module initialization within the --update=all option. Else, SQL or OOOR/Pythons scripts might be called at module init (if OOOR scripts, we could have a method to execute pure SQL statements like DDL on OpenERP server, just for the migration purpose). In any case, how do we make those migration (data + DDL) scripts? Well, of course, like Sharoon said, I always thought it would have been cheaper if migration where thought upfront at each commit (Or well, may be not as so many things where amateurish in the past that OpenERP required so many changes to become decent). I even proposed to throw up a tool that would have subscribed to the RSS of commits where community / OpenERP could have collectively commented migration snippets. Well it has not been done, so now the situation is we have OpenERP v5 and OpenERP v6 and we should deal with that and that will be very rock'n'roll. What we started with OOOR yesterday, is a simple 20/30 scripts that will connect to 2 OpenERP installations (v5/v6 or pre/pos module installation), analyse the fields definition of all objects and dump a diff in user friendly format. This script will explicit things like in v6 a sale.order should now have a mandatory company_id key, so the migration script should provide one. Well this should facilitate the work of building those scripts. Even the guys who will buy OpenERP S.A. scripts will be able to check them when they have an issue (and yes, there will be blood). BTW, if migration scripts start around 1 800 euros, well it's simple, we, for instance, have some 2 customers who won't be able to pay that + all the manual work from us (or certification work). Not to say that: our ~8 customers all have at least some 6/7 custom modules so that OpenERP benefits are worth the bugs/limitations. So, sorry, but I don't buy for a sec, anyone else than the integrator could migrate customer at a decent cost. I don't buy the "upload your database and get migrated" at flat price for a sec fro anywone using OpenERP v5 in production for real and not being a direct OpenERP S.A customer. Why? Because the decent OpenERP S.A. resources (provided the difficulty of the task), will soon be totally unavailable (we all see how hard it is to hire decent OpenERP consultants), the other will not be able to do the job properly or any cheaper than those who created the modules. Certifying the modules will be too much expensive for lots of users, it will bloat OpenERP S.A., it will not work in most of V5 case to achieve reliable V5/v6 migration. Then how do we do? Well, the integrators should have the scripts to do the migration. But if the partner buys the script from OpenERP S.A., what will warranty OpenERP S.A. that the partner won't reuse the script for the other customers without buying it again? Then I see no practical solution for OpenERP S.A. in trying that specific migration business. Of course, if, in the future, OpenERP gains more quality, like in V6, if modules become so generic that less customizations are required, if OpenERP real user base gets large enough, if scripts are thought during the implementation with rigor, then may be this could work in the future, I just don't see it working for v5/V6 because working v5 OpenERP installations where to much cowboy styled as I said. Fortunately, lots of OpenERP users could simply close year 2010/2011 on v5 and start next year on V6 after migration some strategic data in an ad-hoc way and after having their modules made compatibles (which isn't that hard). But I hope to see community based/public migration scripts emerging because that the only way I see it possible for all the small companies (say less than 10 people) using OpenERP v5 today and who will want a full migration. Fortunately also, there is no rush, those guys which are okay with v5 could migrate to v6 at the end of 2011, but obviously the more they will wait, the harder they will find any skilled integrator wanting to do extension on their v5 version. My 0.02 R$ ------------------------ Raphaël Valyi CEO and OpenERP consultant at http://www.akretion.com -------------------- m2f -------------------- -- http://www.openobject.com/forum/viewtopic.php?p=61352#61352 -------------------- m2f --------------------
_______________________________________________ Tinyerp-users mailing list http://tiny.be/mailman2/listinfo/tinyerp-users
