This talk will focus on how to plan for, and implement, “enterprise-wide” migrations of your Source Database Platform onto the SAP Sybase ASE Platform. While we are focusing our talk on multiple numbers of migrations (tens to hundreds of physical servers), we can easily apply these concepts to a single server migration.
The ASE Migration Factory is a resource management design that emulates an assembly-line process and applies it to the ASE migration effort. Key bi-products from this effort are repeatable solutions that will help all future migrations in your enterprise and a stable platform to build upon future ASE Servers. Every Server to be migrated in the enterprise will be passed through the migration process assembly line to arrive at the other end as an implemented SAP Sybase ASE Server.
In a car assembly line we have the concept of the car moving down the assembly line while resources (people, machines, automation) meet the car in designated areas and attach their own area of expertise onto the car, building upon the previous work or attachments. Certain complex parts such as car seats are manufactured off site according our specifications and we take delivery of this JIT (Just in Time) item and bolt in onto our car. We have various plans or cookbooks depending upon what type of car we are delivering and a record of any special features we have to add for the End Customer. Here is a high-level assembly line for our SAP Sybase car.
For our migration talk, let us assume we do not move the car, in our migration assembly line, the Database Server (aka car) remains stationary and the various software, hardware, disk (aka bolt-on parts), base configured ASE Server (aka plans) , SAP Sybase Consultants, DBAs, in-house Experts (aka people) and software processes and Consultant Tool Kits (aka automation) are brought to the Database Server (aka car). We still maintain a strict order of assembly as per our plan but we only bring in resources to build, as needed. This is a key concept: we are using a JIT approach to sharing resources.
In the Migration Factory concept , the SAP Sybase ASE Server does not move while we (people, automation and resources)assemble the specific Database Server according to our plans of assembly. Any software object needing extra attention will be done remote (to the Migration Factory) and delivered to be assembled. This state of fluidity allows us to remain flexible to bring in the right resources at the right time as well maintaining a steady movement towards the end result; implementing our SAP Sybase ASE Server. These are key concepts of your Migration Factory.
A Migration Factory is:
- a concept that allows us to manage resources to effect the migration of a Database Server,
- allows the division of certain tasks to given to offsite (with respect to the Factory instance) resources to ensure concurrence of effort,
- dependent on project management and scheduling. These are key design points to ensure all resources are used in an efficient manner,
- a design that can have concurrent ASE Server builds proceeding at different stages through a single Migration Factory (refer to the following diagram Builds A,B,C are at different stages),
- designed to be a modular (stand-alone, self-sufficient) unit with hardware, software, tools, resources and plans to migrate and support an ASE Server migration,
- designed to have a pool of resources that will grow and shrink according to the concurrence and complexity of the migrations through the Migration Factory,
- applicable to one to hundreds of migrations,
- designed to co-exist in a symbiotic relationship with other Migration Factories.
A Migration Factory is not:
- an actual factory – it is a concept tailored to your environment,
- rigid. This concept can and should adapt as your environment evolves.
For a typical starting Migration Factory we suggest a full-time Project Manager and a “source database” DBA that follows the migration of their specific Database Server from start to finish. This will allow the necessary skills transfer into the SAP Sybase world. The number of concurrent migrations done by the Migration Factory instance depends upon the available number of “source server” DBAs available, the scheduling of hardware, software resources and the pool of SAP Sybase Consultants assigned to the Migration Factory. There are many moving parts and the project management of the Migration Factory is key.
Expanding this concept out to the Enterprise is simply a duplication of the single Migration Factory. A large migration can have more that one Migration Factory present, each being self-sufficient from one another but certainly profiting from shared information and the pool of available resources. As your Team become more proficient in the migrations, the resource (SAP Consultants and DBAs) pool can be reduced or moved to other Migration Factories.
Shown is a enterprise Migration Factory schema with a remote Code Factory (aka Off Site Manufacturing) used to supply additional code level changes.
This Migration Factory design has been in existence for a while in the migration world and many iterations exist. It is definitely an idea that has merit and should be under consideration for any enterprise-wide initiatives.
If you have any additional questions or comments on this Migration Implementation concept please do not hesitate to contact myself or the SAP Global Services Team.
|and please don’t forget ……..|
Follow the “Database Services Content Library” to access the entire series of Database Services Blogs and join the conversation on Twitter @SAPServices
Learn more about SAP Database Services here http://www.sap.com/services-and-support/data-and-technology/database-services.epx