From spec merge point of view I agree with Don approch. Custom objects (system code 55-59) always merged and customized standard object evaluate if reapply customization or going with standard processes.
Bruno don't forget all the tasks included in an upgrade process from an older release to newer. I report here a lists of main activity during a release upgrade:
1) Install new JDE software on deployment (Release 9.0). For example this installation process update windows registry or folder (differently by E8.12) and install planner db (MSDE/SQLExpress or Oracle Express) different from E8.12 (supported only MSDE/SQLExpress)
2) Install new JDE enterprise server (Release 9.0). And configuring your EO 9.0 database
3) Define an installation planner and submit Installation Workbench. This steps include the following
3.a Initial Tasks (copy Media Objects, copy system table....)
3.b Location Workbench
3.c Datasource Workbench (define new datasource, f.e. Central
Objects - DV900....)
3.d Environment Workbench (define new EO 9.0 environment)
3.e Machine Workbench
3.f Control Table workbench. Merge UDC, Tasks, datadictionary
from older release and new control table
3.g Table Conversion Workbench. Convert Business Data tables
format from older format to the new
3.h Specification merge. Merge programs
3.i Package definition
In my opinion these are the main tasks, so Bruno you understand that if you try to migrate tour EO 8.12 to EO 9.00 simply merging your program you must to execute manually a lot of activity (update tables with new version, modify jde.ini, jdbj.ini, jas.ini, copy UDC from old to new release ...).
If you want to try, my suggest is try with an incremental approach:
1- First of all install standard E9.00 software on a new hardware
2- Merge your data dictionary and program in the new release (custom object merged and customized standard object evaluate what reapply and what not)
3- In a second moment you can analyze different on database for business data tables beetween E8.12 and E9.00. JDE supply a list of different tables and corrisponding table conversion to convert data.
4- Analyze differences for control table (tasks, UDC...) in terms of new table and in terms of values (for example custom UDC create in the old release)
5- I suppose you're customer doesn't want to reinsert on the new release all system tables (users, users password, roles, printers, printer-users associations, job queues...), for these, check if you are able to reuse point 3.a
After a lot of (a lot lot!!!) tests MAYBE you are ready to go live. I say MAYBE because in this post, after 10 year of upgrade, I reported main complication about upgrade, but surely I forget something.
However Bruno ... good Luck
gg