Implementation Plan/Migration

Lifecycle development
Project management
Dear colleagues: I would like to ask what constitutes a good system implementation/migration plan? Are there any standards for this? What are the minimum contents of an effective implementation/migration strategies? Please advise. Thank you.

Answer Wiki

Thanks. We'll let you know when a new response is added.

The qualifications that would deem a migration plan as the paramount plan would be the simple notion that it possessed comprehensive migration strategies that were proven with execution. This plan would address the general aspects of deployment and include the best configuration practices. As said, only general aspects would be detailed, simply because each environment would encompass characteristic specific to that industry.

Discuss This Question: 4  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • KingTut
    I'm sure one of the standards creating wizards have a plan - - but, it's probably way complicated. System migration, particularly from one commercial product to another, requires you determine your current state and business processes and then map them to your future state and processes, as determined by the selected product. For broad systems, like ERP, that touch all departments, the "As Is" and "To Be" exercise can be a huge undertaking. This is when it's imperative that business departments provide manpower to the migration project team. Ideally, it will be left with the team through to completion. It's always a good time to look for business process improvements and obsolete reports that can be dropped. Business process redesign is almost always required during a migration just because of how each system was designed - - it will be larger if the original system was a custom build. Whether the "To Be" custom reporting requirements are more or less than the current environment is determined by how well the canned reports match the business need. Data migration will move in parallel to the system migration, If the systems are document management environments, may require extraction and/or conversion depending on the original system design, in addition to attribute data migration. Finally, you have to determine the roll-out strategy. You must determine if a "Big Bang" approach makes sense - - where all product modules are implemented at the same time - - and each site gets the full product as close together as training allows. Otherwise, fewer modules and/or spreading out the roll-out over time may make more sense. Don't be put off by the size of the project - - the key is to break all the activities down into managable chunks and the timing is controlled by staffing/budget limitations. You can certainly look for implementation support from the consulting companies. Just be sure to find a match of experience with the product, experience with your industry and fit with your company culture for the highest chance of success. Understand that the people/cultural issues will be the biggest hurdles, as most people have a natural inclination to resist change.
    0 pointsBadges:
  • SidSeton
    In any migration, it is wise to remember that there is a business aspect, not just a software migration. The business needs to be completely involved both as the data owners, and the users requiring training. Early top level involvement in any migration can reduce the amounts of data to be migrated, increase the cleanliness of said data and the confidence in the new system. Many migrations appear to 'fail' due to bad data becoming visible after the migration, and the software being blamed, leading to a lack of user confidence reaching upto the CEO.
    95 pointsBadges:
  • Rshyleshnair
    An implementation plan must be done in steps. Start to document your existing "As-is" business processes by functional unit, map it out visually if you must, identify your pain-points (bottle-necks that cause redundancies and inefficiencies), document what you need your system to look like within each functional role (researching best-practices in your industry similar to six-sigma practices etc. is a good idea) and then you are able to clearly identify your "Gaps". Based on your gap analysis, you are then able to come up with the steps /tasks you need to implement from your "As-is" to "need-to-be" state. If you are going through a full blown implementation of an ERP, you need to identify all the configurations and setups and go through the SDLC model(s) and set up conference room pilot plans (CRP1, 2 and 3) (this includes an extensive, phased testing plan before your actual cut-over (go-live plan). Your CRP 3 could be a mock "go-live" simulation to see what the scenario would look like at actual go-live. Identify your change control mechanism, issues management procedures, your risk management, your business process measurement success factors ( KPI's), identify your milestones of the project, deliverables of your project and your training and documentation plan. That's pretty much it. If this project involves outside vendors/outsourcing, then you need to have already done the business process documentation and defined your RFI and RFP (request for proposal that includes your project scope definition). Hope this helps.
    0 pointsBadges:
  • Gianfra8nco
    Who has a migration project plan aligning to a Vendor application replacing a legacy application?
    10 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: