UPGRADE PROCESS:First of all there should be detailed analysis on feasibility of upgradation of customized schema to newer version and other integration

Start with schema upgradation of 2009x to 2013. 2013 installer itself upgrade schema to newer version but it will fail at many places due to customized schema which need to be tracked through logs like installSchemaInstallerV6R2013x.log and implement hotfix for issues. similarly after upgradation of schema you will face issue in code like when using a field type of programHTMLOutput, the JPO specified must return a stringin XHTML format, this XHTML format could be of latest version in 13X.

Steps:-

1. keep your 9x schema in tablespace and start installing studio platform, point out your old schema and then there is some mql command need to run.

Use following commands for upgrade.set context user creator (password );verb on;Upgrade physicalid;Set Environment variable:- MX_SKIP_LXFILE_UNIQUE_ON_ERROR=truerestart MQLvalidate upgrade;upgrade;validate index vault eService Production;index vault eService Production;validate index vault eService Sample;index vault eService Sample;validate index vault eService Administration;compile all JPOs;

2. > Install the live collaboration server , BPS, centrals and so on.... :)

Frank is correct that you should work with someone that has gone through an upgrade before. There are many variables. The olde the baseline schema is, the harder the upgrade. The extent that the customer has customized (overriden) funcitonality also significantly impacts the upgrade. This is a highly summarized reply, but some of the things you need to determine. What is the Major and FP version you are moving to. Note that your upgrade steps will require your to run the major version installs and incremental fix pack installs in the upgrade process, never just upgrade to a Golden Level as it is full of issues. If customization and confugiration/extension has occurred, make sure the customer has properly identified the code and schema elements and has followed the recommended practices for doing so. If not, you should use the upgrade as the opportunity to correct this. FInd out the cupport technical stacks for your upgrade environment, You will need to see if OS, Db, App Server, CLient changes have occrred and where you can upgrade some things in common between the old and new environments. Create a non-recurring software pipeline that includes a pristine base and upgade version so you can easily identify issues with any customer changes or upgrade issues. Also replicate your baseline and perform the upgrade steps on these environments to validate that there no issues in the upgrade scripts. You will also want to run schema comparisons old and new in a configured environemtn to understand where changes have taken place and lastly have regression scripts to test functinality after you have completed your upgrade. Practice the upgrade multiple times on the metadata to get timing and steps well documented before you actually upgrade production. I also recommend that you run DB Healthchecks through DS Customer support before and immediately after the production upgrade to make sure your system is working as expected. Again, this is highly summarized, as Frank mentioned, you will save a lot of grief if you find someone that has gone through it before.How many centrals you are having in your instance,

Is it only Engineering Central you are using which you are planning to upgrade.And did you follow the DS recommended way to customize the code ( regarding the naming convention in writing the custom JSP/JPO etc.)

If answer is yes, then It should not give you much trouble to you.

If you can provide exact details of custom current Env. (2009x) and Target Custom Env details (2013) with exact Fix Pack number and Central used in environment (Java Version/OS Version/DB Version/FCS Machine OS etc), then may be group can help with their experience, who ever done these exercises.

And before you take up this project just make sure your hardware/Java version/App Server in compliance with target Release if not then first task you may have to take up the upgrade of hardware etc.

Get the program directory/Release Notes from Vendor and also Documentation if you are able to get it will be handy but get Get Program Directory/Release Notes for Sure, you need that.

As a followup, I will add that there are at least two major database schema changes between 2009x and 2013x. The odds are that you will have to upgrade the database in multiple steps. (I would guess at least 2, possibly 3.) A lot of this depends on the nature of the data. I have seen some upgrades go from 10.x to V62012x in one step, and I have seen others take 3 steps to span the same versions.

As Jack said, upgrading the web stack is also a major project, especially for the range of revisions that you mentioned. You will need to set up test environments to validate the upgrades. You will also need development environments to re-do any customized interfaces that the customer is using. As I recall, there was a major change to the JAR file structure somewhere in the range you are dealing with. That means a lot of work just getting the customized stuff to compile. For a large, complex installation, this could easily be a 6 month project with a staff of 6-10 people.