Migration of Business Database systems
Migration being the process of translating X into Y without changing
- the desired outputs
- or the business features
- or the project scope
and without necessitating that the inputs to the system change
Business Analysis and Data Analysis are part of the preparation work for migrating business data that is incorporated into different types of complex systems. This series of articles will help you understand how one approaches the challenge of upgrading or migrating databases used in typical computer systems.
Business intelligence and process automation are currently a fast moving technology arena, technology based tooling evolve every 2-3 years; can you be certain that your competitors are not gaining an advantage by upgrading their systems or using better business intelligence tools?
Analysis incorporates a process of investigative research, establishing business needs, devising new features, performing technical data analysis, task planning, and helping you to regulate change requirements. Plus, data analysis focuses on assessing data flow, modelling how data will be transformed and integrated into your business, as well as any such existing data processing activities. In addition, data analysis incorporates examination of malfunctioning applications, malfunctioning data processing algorithms as well as planning new data process automation,
A BA – Business Analyst should recommend strategies based on demands identified from a carefully considered audit of your business needs.
This first article in the series explores aspects of database migration work planning and analysis; later articles will outline some of the different types of database migration, explore aspects of migration testing – migration work-flow – and will review some typical lessons learned.
- »» P1: Business Analysis
- Pn pending: Data Analysis
- Pn pending: Types of migration work
- Pn pending: Test Data and Migration Validation
- Pn pending: Migration work-flow
- Pn pending: Discussion points / interesting Migration Issues
- Pn pending: Deployment strategies
Justifications for migration projects include moving away from a legacy or unsupported technology, gaining performance improvements or integrating data with other enterprise systems. Assuming that there is sufficient budget to pursue such goals, the business analysis role should be to establish key targets and the best strategies to deliver the principal value objectives for the company.
Business Analysis run-through: When you first come onto a new project, you need to quickly clarify the type of system architecture in use, the critical business processes, the kinds of legacy tools in use, any tools and dependencies upon which stakeholders rely. It’s useful to assume that the business may be living with features that do not work correctly, in this event, we want to discover what fixes or workarounds are in use by folks, to mitigate against any existing malfunctions within the system.
Considering the context of the system to be migrated, we want to discover what task-work-flows or business processes require the use of the legacy database. After this work, the business will need precise instructions and planning on how to go about the best-practice-ways of incorporating migrated features back into the business work-flow for teams or departments.
During post migration, you will be coaching teams who are using the migrated system to keep records of what they are doing with the replacement system. This is important, just in case the migrated system fails to perform to expectations. Its good advice for folks using the migrated system that in the event of detecting any problem or failure, that the most important piece of information for them to collect is not so much, the error codes or error symptoms, it is in fact, to keep a record of any steps that the user was carrying out prior to witnessing the problem! Diagnosing this evidence of procedural steps, completed prior to witnessing a failure, will facilitate debugging and correction of any problems.
So, post migration record keeping i.e. getting people to keep records as they perform data entry or run reports is a good strategy just in case the migrated system needs to be corrected. Moreover, keeping records will also allow the business to roll back any changes to return to using the original database that was in use prior to performing the migration; this activity is about restoration of the original system so that the business can continue to do its work while further migration improvements are implemented. Business risks will be related to underestimating the impact to any business functions if / when migrated features do not work, or when faulty data has been migrated. The impact of not being able to conduct normal work, and having to spend more time making corrections to systems is an additional business stress and cost factor.
Similarly, developers will also need some instruction and planning on how to go about the best-practice-ways of performing data transformation and database migration; this may involve some regression testing and involvement of stakeholders to help validate any technical or business assumptions being made during testing.
On top of that, there are times when the business will want to take opportunities to add new features to the product, at the same time as doing migration work. Whilst, we want to discourage the mixing of migration work with aspirations to add new features, because we have a need to simplify test challenges, there are times when, from a business perspective its is important to build new features into a product’s design. Building new features is easier post migration after business acceptance testing has confirmed that the new system is stable.
It is easier to accomplish a development budget sign off when business milestones are merged, reduced or simplified.
In developing new functionality (i.e. adding new business features), it is helpful to work with users at a higher-business-task-level to grasp the goals of their activities. Sitting with users, while they perform their work, helps to clarify their thinking processes, frustrations, difficulties and understand how they actually complete their work tasks. It’s often at this point that one can understand any software deficiencies, poor screen ergonomics design, system performance weaknesses / improvements, business workarounds. When considering business workarounds, it is quite common for teams to establish procedures to correct problems when a system does work correctly; this information is useful for testing, its also helpful to understand what the business wants in the way of a correction to fix a known system issue.
The difference between greenfield start-up projects and migration projects is that significantly more of the overall requirements effort will normally be spent on understanding the current system usage / flaws / architectural or system dependencies / legacy technologies in use / data latency issues / performance limitations / responsibilities for managing data and security / plus any business aspirations to make improvements. The business analyst role is to capture such details and to create a work plan to help the business move forward.
Preliminary project scoping: –
In the beginning of a migration project there will be a few conflicting points of view between folks, there will be a number of discussions on what the business requires. It is useful to request the original specification and review any existing hardware (appropriate computer server equipment, RAID configurations, operating system etc.), this will help to clarify how effective the original specification was, it is sometimes desirable to keep parts of the original system as it is! From a technical perspective, computer machine names and IP addresses and passwords are all candidates for trauma and things going wrong during migration.
Establishing the working system base line for the current system will facilitate the challenge of how to test and validate any existing system(s). You might need to make some recommendations for hardware upgrades as part of the overall software or database migration work.
System Baseline: It is not best practise to migrate a faulty system, its important to explain to stakeholders, and emphasise to the business, what the business risks if doing this are, and to underline some of the technical difficulties, should the system to be migrated NOT be stable. There are of course exceptions to this rule, corrupted data records in side databases is not unusual. Sometimes the business is not aware that their data records are incomplete, missing or corrupted. This is a challenge for a data analyst to repair corrupted data records, during migration, however, the business analyst can help a lot if they educate the business as to their need to establish how faulty data is to be handled. Collaboration between all parties will help to deliver a successful conclusion to this work.
- Scoping: In the beginning we need to discover how much change business folks will put up with, what innovation boundaries exist. From another perspective, system design will be affected by the amount of data processing that is required, so questions to ascertain how many users depend on the data and related data processing systems will be useful. And from a technical perspective, what are the data flow volumes / database size, will also be important.
- Business Technical: Questions such as How does the company make use of its data; what kind of use is the database going to be put through, this will help to surface some of the technical challenges and give some understanding of how stake holders view the level of difficulties for the migration work. There are many possible ways a database can be used for example as part of a business accounts system / part of a reporting business intelligence processing system / web site, …, and so on).
Performance estimates (Number of end users, record retrieval and record search times, time taken to go through key business data entry processes, processing time PLUS data capacity for data volume / business intelligence reporting throughput, ETL data processing speed/volume). Sponsors and stake holders need to be aware of any design limitations for migration work; in addition, stakeholders need to understand exactly what such changes will make / mean to any of the business services that they plan to launch on new target platforms.
- Responsibilities: Questions concerning, who manages the database security / backups / upgrades / index maintenance / … / and so on. How many cost centres / teams / people are dependant on, or make use of data within the database to be migrated? Establishing responsibilities is critical to ensuring that all peoples who are impacted by the changes, are also committed to the change process. Everyone needs to be on-board. otherwise, there will be politics and some emotional trauma down the line; this is an obvious business risk.
- Timing: Scheduling data migration and migration testing for different departments / teams. Incorporating the commitment of key peoples, to collaborate in testing and validating that migrated features are acceptable is important. This will facilitate the willingness of stakeholders to sign off check-list items. This in turn will help to secure an agreement that milestones have been achieved and delivered to the satisfaction of the business.
What are your clients needs? There are many possible reasons that necessitate database migration: – A company-merger requires data from two systems to be merged into one holistic database solution. A common set of front end-user screens / applications need to have access to data from several databases using a warehouse based architecture?
When meeting with key personnel, some of your questions will invariably trigger ideas for enhancements or new products/processes/systems for the business.
Meetings with stake holders need to be short to give enough time to take notes, document key points, issues, action points within the same day as the meeting. Unless you have a photographic memory, meeting with too many people between writing up your notes is a rookie mistake. Allowing stakeholders time for reflection, time to think through arguments and business needs also helps to establish consensus; successful projects depend on shared engagement and commitment of key decision makers.
In projects where there are incomplete or continually changing requirements, the effect is to cause changes in design thinking and strategies and directions taken by engineers when they are trying to resolve business challenges; this poses a technical risk that can prevent development tasks from maturing to successful conclusions. This can happen in small businesses where there is pressure to react quickly to market changes. When the development team has a number of seasoned developers, this is not to much of a problem, provided that there is technical tooling and infrastructure that can support continuous integration based development. The base design planning must be stable and scalable; if stakeholders are in the habit of changing their minds during project conception, then the projects success will be at risk. A useful strategy is to ask stakeholders to date and also initial the meeting notes, do this whenever important choices are being made. This is most useful later in the project development cycle should a stakeholder forget something, or forget that they changed their minds, we are all human after-all.
The business analysis needs to keep in mind that re-factoring designs and development deliverables, in order to keep up with changing requirements, wastes time and will push back time-line milestones. Its important to provide leadership and keep folks anchored around the core deliverable milestones, Such situations where requirements are not stable, add to the project costs and end up creating unstable systems / products / database systems. Stakeholders need to feel connected with development challenges as much as they need to within reason be able to influence project targets; in this way collaborative trust builds morale and shares the ownership for successful outcomes.
Starter questions for stakeholders
Business analysis is about networking with the right people in order to maximise our time to get to the nuts and bolts of any problems, to learn what ambitions/objectives are in play. We need this intelligence before we can start to understand what directions to take, what advice will be relevant, what goals and strategies to target.
We all have a repository of useful questions that help to begin a conversation with folks that we may not know very well. I find that some questions will work with almost any kind of situation or project; three questions are ample for a meeting.
Who are you planning to meet, what is there role or sphere of influence within the organisation? Do they have a business or technical perspective, its important to direct questions that are relevant to their expertise. As you establish relationships with key personnel, you may discover that there are already established ideas and opinions on what needs to be achieved; this will help you to strategize and champion ideas that your experience and background has taught you, that will be technically viable, cost effective and will deliver business value.
- Tell me about your pain points
and challenges with the system/process/product.
- If this system/product,/process worked as good as it could, what would that look like?
- A strategy question for senior business people; we hope to gain some insights into what business goals are being pursued.
- What are the top 3 things you would change?
- Stakeholders need to prioritize and focus on what’s most important within their team. We want to define and clarify their business needs, evaluate how well their system is working, understand how they will assess a successful migration-roll-out into the business.
- What things would you make sure not to change?
- Understand what works well within the system; why expend energy, changing something that is already fit for purpose.
- If the project or enhancement does not happen, what impact would that have for you?
- How committed will this stakeholder be to a proposed change, are they bought into the process, or do they see the value as too small or not relevant to their situation?
More prospective questions: Can you tell me about any business critical or strategic requirements. What are your main business concerns as you see them? Have you thought about any other ways that you might address the issue? What are your key business needs? What role do you see me playing in helping you migrate your data? Are there any important software products or software technologies applicable to your situation? What would success look like if this work were to be successful?
Migration work-flow summary
The Business Analysis / Data Analysis is concluded; this establishes the strategy and milestones for conducting future development work and deliverable items for the business. Completed data analysis and development work is followed by a number of delivery-roll-out-stages to business functions / teams. In addition, disaster recovery planning is also completed in order to form a safety net to recover the business in any event that delivered migration work is deemed unsatisfactory. The delivery roll-out and optional training is followed by a sign-off that includes post testing and ongoing management of the system for a limited period of time. The business sign-off concludes responsibility for migration work and formalizes the handover of delivered items to the business.
Data analysis perspective: We want to discover how data gets into the database(s), Data inflow from numbers of data sources; other technical considerations are data volume, frequency of data updates. How data values are transformed and translated when data is ingested into the database.
The next article will address aspects of migration data analysis and the work effort required to understand how to go about doing the database migration work.
Thanks for reading, I’m interested to know / learn
Do you agree with the balance of points made?
Have any key issues been missed?