Migration override simplified
Step 1: Examine your Stationery
If you have made customizations in the past, chances are that these customizations may have been copied over to your project file in their entirity which means that they may have some of the legacy files included which can interfere with the newer versions of ePublisher. The first thing we need to do is to to look at the files that are in your project directory and determine which version these files were changed in.
These files were last modified in 2007, and we do not expect you to know when each version was released, but it was determined in Support that these files were from the 9.2.2 version of ePublisher. (This was determined after looking at the 9.3 versions files and noticing that there were many many folder changes compared to the next step where it was isolated to only a few changes in files
Step 2: Locate the changes in the files
This can be done by doing a Folder comparison. For the purposes of this demonstration, I used Araxis Merge to do the diffing, but there are other cheaper/free alternatives. I noticed that the files that had one change in them were the .gif files, so I noticed the few files that had more, which were the pages.xsl and the pages.fti. These are interface customizaitons that we created.
At this point, we are going to start the override process. Just in case we happen to mess up, we will name the legacy overrides "Transforms_old" and create a new "Transforms" folder so that you can begin to put the modifications for the latest ePublisher version into your project
Step 3: Start to migrate the override
At this point you have done your file comparison and isolated the change to these two files:
You will want to copy over the 2009.2 baseline and the 2009.4 baseline files to your project so you are not changing anything in the installation directory:
Step 4: Taking note of the FTI changes
So you have your 9.2.2 version baselines loaded into the project and now you can begin to compare. Remember you are only needing the files that you are changing to be compared, so any other baseline file can be deleted ONLY in your project and not in the installation directory.
In this example, we are fortunate enough to have the changes notated by Development. However, even if there are not comments to indicate code changes, a good merge utility will be able to indicate which changes are made in the file. Also, I find it handy to take note of the line number ranges that these changes have been made so when you are merging the code from the 9.2.2 changed file you will not merge any of the legacy code into your new XSL/FTI files.
Step 5: Taking note of the XSL changes
You will do the same process for the FTI changes, but now you are looking at any of the XSL code changes. This process will more likely be involved, so pay very close attention to what has been changed, and it will be VERY helpful to even write down some of the lines of code above and underneath, where the customization will be inserted
Step 6: Merging the old changes into the new customization
So now you will need to merge the changes of your 9.2.2 files to the baseline files of 2009.4
This is the most difficult, but should be fairly straight forward, if you took notes of the changes in the code. Some users have noted the use of a 3-way merge to compare the changes that are made between the baseline 9.2.2, the changed 9.2.2, and the soon to be changed 2009.4, but I find this becomes more complicated and just going through and noting the changes manually keeps things easy.
Step 7: Copying the "safe" files
Changes in the the Pages directory are considered safe, which means that you can copy these files without having to merge any of the code. Our .asp/CSS/.html installation files have remained for the most part unchanged since the 9.2.2 release, so any changes noted in those files wwould be made by you and not by ePublisher.