UPGRADE = ON THE SAME SERVER MIGRATE = ON A DIFFERENT SERVER (BUT YOU COULD GO VIA AN INTERMEDIATE SERVER BACK TO THE ORIGINAL BOX)
MOST PEOPLE ARE ON A VM NOWADAYS SERVER CAPACITY IS NO LONGER A DECISION MAKER
UPGRADE ORDER 1. OPERATING SYSTEM 2. DATABASE PLATFORM 3. APPLICATION
LINE 500 VERSION 7.1 ENT 2.1 UPGRADE YOUR OPERATING SYSTEM UPGRADE YOUR DATABASE PLATFORM UPGRADE YOUR SAGE APPLICATION WINDOWS 2003 WINDOWS SERVER 2000 SQL SERVER 2000/7.0 SQL SERVER 2005 L2/500 V5.5 L500 V5.0 ANYTHING OLDER SQL SERVER 2008 WINDOWS 2008 SAGE 1000 V 3.0 L500 V6.0
THE OLDER YOUR PRODUCT, THE MORE EFFORT IS LIKELY TO BE REQUIRED
PRACTICALITIES – UPGRADE FROM 5.5/6.0 Bespoke C-BASE programs TESTING Archive Tables Payroll – MUST be on current version Database Triggers & non C-BASE bespoke BEWARE POSSIBLE CHANGES TO INCIDENCE OF LOCKING
PRACTICALITIES – ADDITIONAL FOR UPGRADE FROM 5.0 Disaster Recovery plans Users/passwords cleanup? Printers/Papers cleanup? Security Groups replace multiple menu systems TESTING XML licence Manual re-entering of stocktake card header data
SECURITY GROUPS Required for DA0355 “User Access Permission views” – Sarbox requirement Created when moving from 5.0/2.1 or older Standard migration does one per user (!), DA0355 report goes off into orbit Reorganise into logical user groups after migration and delete excess groups
PRACTICALITIES – ADDITIONAL FOR UPGRADE FROM PRE 5.0 TESTING Processing cycles Report writer reports RWL (aka RSL) (Report Writer Language) reports Forms – Print Menus Messages Screen forms Working Directory/Database Naming RW Transfer files - Data dictionary RW Transfer files – Data “Union” (WIP/routing) files migration to database
PRINT FORMS Manual migration One module/formset at a time Consider re-editing instead of migration?
MENUS/MESSAGES Manual migration One module/formset at a time Consider re-editing instead of migration, bearing in mind effect of security groups?
SCREEN FORMS Manual migration One module/formset at a time Consider re-editing instead of migration? Why? – Because old forms may not support new functionality Old screen edits may have outlived their time!
BESPOKE C-BASE WORK – UNDERLYING SYSTEMS CODE 1.Changed from Btrieve to Btrieve-removed systems 2.And again in Line 500 V5.0 3.And again in Line 500 V5.5 4.And again in Line 500 V6.0 5.Not in Line 500 V7.0, but Application code will require recompilation anyway!!!! Recompilation under new source code is the minimum required, so check the cost/timescales with your reseller/developer BEFORE upgrading!
Processing cycles All batches should be posted All modules should be at period end THIS IS TO REDUCE THE AMOUNT OF TESTING REQUIRED AND THEREFORE KEEP THE COST DOWN This is not mandatory for V5.0+ upgrades but is very sensible!
FUNCTIONALITY CHANGES MOSTLY SWITCHED ON BY ENABLING A “PROJECT” BUT SOME (USUALLY MINOR) CHANGES ARE INTRODUCED ANYWAY N.B. REDUNDANCY OF SOME SWITCHABLE PROJECTS IN LATER RELEASES E.G. DA0219 “100% BACKWARD COMPATABILITY” POLICY (USUALLY!)
TESTING - ADVICE How much is your reseller ACTUALLY going to do? Demand to see DOCUMENTED test programme BEFORE agreeing deal! Work out which gaps YOU are going to have to test Demand to see SIGNED UP & DOCUMENTED RESULTS after migration GET INVOLVED YOURSELF OR USE AN INDEPENDENT CONSULTANT!
TESTING - ADVICE Check Archives have been migrated properly (or at all!) Check spool queue items have been migrated
TESTING – EXAMPLES Row counts of major tables (order lines, gl transactions etc) Reprint invoices, statements etc and check layout Run major reports (Trial Balance, Aged Debtors, FA YTD additions audit trail etc) before and after, check totals/transaction numbers agree Check every menu option launches without error message/popup Data item processing (“Destructive testing”) on copy system
OTHER ISSUES Changed projects/system key settings – do this AFTER testing where possible Copying old data to “spare” companies BACKING UP!!!!! Do a Trial migration – particularly if you have any bespoke/externally connected systems/triggers etc MAKE SURE IT IS PATCHED UP TO DATE! (get list of program versions)
WHO SHOULD PERFORM THE UPGRADE? RESELLER –Wants your money INDEPENDENT CONSULTANT –See above! END USER –Wants to keep the money A COMBINATION OF THE ABOVE MAY BE THE BEST SOLUTION!
RESELLER UPGRADES NORMALLY DONE BY A “TECCHIE”, NOT A “CONSULTANT” FUNCTIONALITY CHANGES NORMALLY DONE BY CONSULTANT SHOULD WORK WITH AN INDEPENDENT CONSULTANT MAY MAKE THAT ROUTE “DIFFICULT” HAS A VESTED INTEREST IN DOING IT AS FAST AS POSSIBLE
INDEPENDENT CONSULTANT WILL BE A SAGE CONSULTANT BY CHOICE WILL HAVE IN DEPTH SAGE KNOWLEDGE, ALTHOUGH NOT NECESSARILY BREADTH LIKELY TO HAVE BEEN THROUGH UPGRADES BEFORE HAS THE “BIG PICTURE” SHOULD WORK WITH THE RESELLER
INDEPENDENT CONSULTANT MAY HAVE A MUCH BETTER UNDERSTANDING OF YOUR SYSTEM THAN THE RESELLER HAS A VESTED INTEREST IN MAKING IT GO SMOOTHLY AND WORK FIRST TIME WOULD BE IDEALLY SUITED AS YOUR PROJECT MANAGER
END USER May be capable of some or all of the work May not have the time or inclination to do it! SHOULD get involved with testing!
ADVICE PLAN WELL IN ADVANCE Ask your reseller for a breakdown of the time quoted Check they are doing adequate testing Check the backup/DR arrangements are adequate ALLOW ENOUGH OF YOUR OWN TIME FOR TESTING Plan for changes to user visibility e.g. Paper/printers/menus/screens DOCUMENT CHANGES AND TRAIN USERS! Consider completing Upgrade and running for a period before introducing new functionality