x Want to participate? Join the group to interact
  • Replies 4 replies
  • Subscribers 137 subscribers
  • Views 6204 views
  • Users 0 members are here
Browse Forums
Announcements
234
topics
29
replies
General Discussion
5k
topics
13k
replies
Sage Data & Analytics
56
topics
95
replies
Sage Enterprise Intelligence
209
topics
408
replies
Sage Intelligence Reporting
121
topics
322
replies
S Orrock

Sage X3 6.5 to V11

Posted By

HI All

We are planning to upgrade one of our clients from v6.5 to V11.  Does anyone have any helpful hints or tips?

If you have done a V6.5 to say V7 , V8 or V9  can you share any lessons learnt.

I am thinking in general migration of a V6.5 folder to V11 will follow the same process as a migration to V7/U8/U9.

I am aware it will be a major undertaking of testing etc but hoping that its not too onerous.

I am aware their are table changes, and database changes.

Thanks for any thoughtful considerations

  • Based on v6.5 to 7 (with NA addons):

    General trick was to do pilot migration on VMs (VmWare or whatever you like) with a bunch of VM snapshots at different stages (premigration v6.5, postmigation prepared folder copy v6.5, clean v7 install, v7 with the folder migrated, (v7 NA addons if used)).
    Testing of the issues after this and moving to real migration based on the documented pilot run.

    1. Make list of all mods and activity codes (I've had a lot of activity code "protection" killed by NA migration utility), having this list helped to recover most of functionality on the new system.
    2. v65 to v7 required clean installation - so I made a copy of existing 65 to VM - helped a lot.
    3. Pilot folder migration on VM with clean v7 (make snapshot) - I have some DB issues not being detected by consistency checks - had to go back and fix db manually - it halted folder migration completely - with no information how to reset (load snapshot - restart) ....might be fixed in v11.
    4. if WS are in use make sure the client(s) modified for new authorization mechanics.
    5. if there are specific products from the partners - get new versions before migration.
    6. if NA addon for BOL was used and you need historical data on new system, manual export will be required.
    7. Some modifications can conflict with new record lock mechanics. I do not recall exactly, but I think I had to rearrange some database transactions in 4GL code to prevent error. (Obsolete record. Transaction stopped).
    8. Classes - if you had some activity codes protection on v6.5, added tabs might not be populating with the upgrade.
    9. Reports - test - fix data models, or redesign v7 default reports.

    The process is trivial, but time consuming (can be done by following the documentation on clean system, but requires some acrobatics on heavily modded systems). V11 migration might be easier.
  • in reply to SAV

    Hi all,

    We upgrade one of our customer from X3V5 to X3V11. Some specific are used and generate error "Obsolete record - transaction stopped". 

    How do you resolve it ? Do you have code sample ? 

    Thanks for any help.

  • in reply to NMA

    It is mostly moving the transaction from one action to another. Could be specific in your case. You may be modifying and reloading the record after your [F] class is loaded (for example in INIMOD) so you need to move it up a bit. Search article 30-10725 in online help, it describes why this error is generated.

  • in reply to SAV

    Hello,

    Thank you for the first answer, but can you share what tools/processes/documentation you used to accomplish the upgrade?

    Thanks.

    Mohamed.

*Community Hub is the new name for Sage City