1 CASE STUDY: Platform Migration Mike Furgal Director – Managed Database Services BravePoint

2 Introduction- Mike Furgal Progress Employee from 1989 to 2012 Progress Employee from 1989 to 2012 Joined Bravepoint in 2012 Joined Bravepoint in 2012 Progress/OpenEdge Database Expert Progress/OpenEdge Database Expert

3 Introduction - BravePoint The Largest OpenEdge consulting group in the world The Largest OpenEdge consulting group in the world QAD Alliance Partnership QAD Alliance Partnership Founded in 1987 Founded in 1987 Specializes in all things OpenEdge Specializes in all things OpenEdge QAD customizations 4GL/ABL coding Database Services Much much more…

4 Why Change Platforms? How old is your DB Server? < 2 years? < 2 years? < 3 years? < 3 years? < 4 years? < 4 years? > 5 years? > 5 years?

Doesn’t seem that long ago.

6 Service Wire – Case Study Service Wire Industrial grade wire and cable. Employees: 375 Revenue: 300MM Started in 1968, 3 manufacturing facilities VA, TX, AZ About 4,000 products

7 QAD Environment Live since SE with NET UI users all using NET UI Bolt Ons CSS 32soft QCS – ProtoProgress Optio – Forms Design

8 Service Wire was experiencing machine crashes over the past year. These unplanned outages were unacceptable to the business. Hardware and OS diagnostics were run, but did not solve the problem

9 Solution Decided to virtualize the environment.

10 Phases PlanningTesting Cut-over/Go Live Post Go Live activities

11 Phases A 3 month effort overall

12 Planning Determining all the access paths to QAD Determining all the places where QAD application called out What are all the bolt ons

13 Dependencies Graph

14 Dependencies Doc Description How were they related What function did they server What means where they connected to each other

15

16 Testing Built a copy of the production environment Install OpenEdge Copied QAD Configured the NET UI Copied all customizations Recompiled the application Brought the data over

17 Testing Tested each aspect of QAD Data Entry ERP Month End Etc Tested each access path Documented what needed to change to get access to the new machine name

18 Testing Challenges Getting the new system to match the old system Moved from RH 4.3 release to CentOS 5.8 Missing RPMs Sizing the new machine The Physical Machines disks were faster than the Virtual Machine disks

19 Testing Near the end of the testing processes a cut-over date was determine. From that point forward there were go/no-go meetings every Wednesday with all the stakeholders

20 Go No/Go Included all stakeholders People doing the testing People representing the business An open forum for people to discuss problems and scheduling

21 Go Live Rehearsed several times during testing Minimize downtime Data Refresh from production Hostname updates

22 Post Go Live After the go live there were things that needed to be done Reimplement the DR environment Performance Tune Fail over test

23 What went well Had a good framework for vetting problems and issues Early identification and assigned them Experts available to solve technical issues around QAD and the OS

24 If you had to do it again Take more time in unit testing We were optimistic that setting the go-live date

25 Problems Changed the go-live date 4 times Go/No-Go meetings on Wednesday (good thing)

26 Side Benefits Upgraded OpenEdge from 10.2B04 to 10.2B08 Allows for better tuning options A thorough understanding of the QAD environment Found flaws in the fail-over scenario Confidence we could do it again

27 Summary Hardware has changed dramatically over the past 5 years It may be time to revisit your platform Platform migrations have many benefits Always good to leverage expertise of people who have done it before

28 Questions Answers ? ? ? ? ? ? ? ?