As an introduction to these blog sessions I will assume you are currently on another database platform and this can either apply to an SAP or non-SAP application environment. I'll touch on both briefly in this and upcoming blogs. If I was to start anywhere on this broad and far-reaching topic, I should start with a high-level look at the migration effort, the MIGRATION CHECKLIST. An Oracle to SAP Sybase or Microsoft to SAP Sybase migration project should be divided into individual sub-tasks of:
- Planning the migration
- Designing architecture migration
- Implementing schema migration
- Implementing data migration
- Implementing application migration
- Implementing operation migration
- Validating the migration
Planning for the migration really means to develop a technical understanding of what is currently utilized in the database layer, how successful is the current database layer in meeting your goals (technical and business), and technical support issues and growth patterns. Target dates should also be recorded. Once we know how long a typical migration takes and the number of people to support a migration then given the total number of servers to be migrated we can work out a process on how to actually do the migration.
In the planning stage we would need various critical pieces of information. I'll give you an idea of some of these and why we would need them.
Total number of Production Systems to be migrated:
That seems obvious for planning. Notice though we do not focus on the other supporting systems for this landscape: development, test, QA, etc. Our focus is to migrate the production system and we tackle this one first, all the other systems are either a copy of production or a sub-set of production. In all non-production cases the migration path is far easier than the original migration of the production system.
Overall data volume: Depending upon the migration window available to us (as in a weekend...say 24 hours, including roll back time) we need to ensure we can migrate successfully and test the finished product complete with the bells and whistles in time for Monday morning. It’s one of the most critical considerations to any migration. A rough rule of thumb is to estimate 10 GB of data being converted in 1 hour....... if one estimates we have 48 hours in a weekend, then we could do a 480 GB database conversion ..... but the reality is we would want to definitely test it and actually see what we are left with. Alternate planning strategies are to use archiving or bring over some of the historical data beforehand or using SAP Sybase replication Server technology to mimic a real-time cutover. all considerations are part of the planning stage.
Server complexity: If we can ignore the data for a moment, your database server consists of tables and compiled code, be that triggers, procedures, statements. Being familiar with the Database layer you have probably heard about ANSI Standards. Any SQL code written to ANSI Standards becomes at it’s most ideal: Database Vendor Agnostic. Very few shops achieve this simply because the database vendors have added options that are non-ANSI to increase usability and performance that is specific to their own database product. This is across the board. Because of this added complexity, migration is not as easy as reverse engineering the code and applying it to the target SAP Sybase platform. Fortunately there are SAP and third-party tools to automate this conversion process. In later blogs we will introduce these. Complexity of the compiled objects and the number of objects to be converted enters into the planning stage. Conversion, even automated conversion takes time and this duration of change and test is part of the planning process. Estimation tools that catalogue the code complexity and estimate the duration of code migration are critical in planning the overall duration of the project. Code migration is judged to be the most effort in any migration. The closer one can write to ANSI standards the less the effort will be.
Staffing: Staffing for a migration depends upon a number of factors the least of which is having the number of physical Staff Members to do the actual migration. The more trained you and your Staff are trained in SAP Sybase technology the better you will be for moving the migration effort along. While that’s ideal I find that initially I am involved in the heavy-lifting and as Clients get more attuned to the migration process and after getting some formal and informal training they tend to take things over and I more into the role of "trusted migration advisor." It happens by default.
So now we have an idea on what information we need to make a planning decision. I find that a couple of days on site for interviews with Data and System Architects (preceded by a questionnaire to get everybody thinking about their current environment and what needs to be changed) is a good way to hit the ground running. For some clients we launch into the migration planning quickly followed by Phase 2, "Designing architecture migration." For those that are new to SAP Sybase technology we can give an introduction to the technology to get everybody thinking and designing as to best utilize SAP Sybase technology given the current situation. Knowledge going both ways, is key here.
One last mention regarding the Planning a Migration. Planning for a single or one landscape migration is very different from planning a migration for 50 to 1000 Servers. Enterprise Migration Planning takes the scale of planning up a notch. For enterprise planning, we use a planning or logistical concept known as the SAP Sybase Migration Factory. In a nutshell it takes the concept of the Model T assembly line and applies it to an SAP Sybase migration instance. More to come on this.
That’s it for now, next blog I will focus on the next step in our migration high-level steps: Designing architecture migration.
