Introduction\n\nSpecialised software tools can prove integral when completing tasks efficiently and effectively, and our reliance on the data that we produce in such tools cannot be understated! It's why we have to keep our eyes peeled on "Service Outage" notifications, whether they are planned 👌 or unplanned 😒 (and normally very sudden). When we rely on tools to "Get the Job Done", it is essential that we have an operating environment which ensures that such tools are reliably available otherwise we risk downtime, frustration, and finger pointing.\n\nNot only do we have to worry about routine maintenance and unscheduled downtime, we also need to worry about application availability when our software and the required dependencies need to be migrated to new servers and/or networks. This can happen for numerous reasons, including when a company purchases another company and needs to migrate software to their network, as well as when data classification is changed and the software needs to put on more secure architecture. This can add a layer of complexity that needs to be properly managed to ensure minimal service disruption, as we don't want to anger the users and give management/clients unnecessary headaches 😂😬.\n\nSo how do we ensure a smooth(er) migration, with as minimal downtime as possible and subsequent access sooner rather than later? Here I give insights based on my experience migrating software for various project teams. I shall try to lean on non-technical, and give an overview that project teams will likely need to consider so they aren't cut off at the knees! I aim to give you the questions you need when that scary migration announcement comes through 😎.\n\nAn unplanned outage for a vintage car 😂\n\nWhen Software Has to Move to Another Network\n\nSo you've identified chunk of (heavily-used) software that needs to make the leap from one network to another and you want to make this process as seamless as possible. Perhaps you've been acquired by another organisation, or the data has been reclassified and is to be moved to a secure network. Have no fear! Here's some important elements that you will need to consider.\n\nWhat the Timescales Are: At some point, the system(s) shall be moved, and there are some important dates to consider and plan around. When will access be revoked, and when is the date of migration (sometimes the same, but not always). By knowing these important dates, you can organise the actions of your team and any supplementary processes.\n\nWhat the System Dependencies Are: The system you use may rely on other system(s) to provide you with the service. This can include a database system for data you produce, as well as a file server to provide the files you use. By moving your main system without these dependencies, you will GUARANTEE chaos on your new "go-live" date (have seen this with internal IT rollouts 😂).\n\nThe Users of the System: When your system has moved to its new home, all of your existing users will all need a key to use it. The system will be useless if your users cannot access it, and steps must be taken to replicate their accounts permissions. You will also need to PROPERLY COMMUNICATE the migration actions every step of the way to ensure that everyone concerned understands what is happening and what is expected of them.\n\nAny "Special" Configuration Parameters: What I call the ultimate GOTCHAS. These are the gremlins in the system that will become visible at the WORST possible time, and can only be stopped with advance planning and system understanding. This could be as "small" as a lost administrator password, or as intensive as a VPN connection to another network so that software licenses can be acquired. Both examples would render your system inaccessible without a proper solution.\n\nThe Limitations of Your Central IT Department: Let's face it, despite the requirements that come with the job description, your IT department can only do so much with the resources they have available which may unfortunately conflict with your planned milestones. Have you been provided with priority support? On top of this, they may not even have in-depth expertise in your software, especially if the system you are using is client-mandated. Finally, they may have experienced cutbacks, and in an extreme case, not be very good 🤐.\n\nLady with a headache after having to deal with migration woes\n\nThese elements must be fed into your migration plans to help ensure a smoother transition. Neglecting any of these will likely lead to frustration, headaches and solution and project delays. Nobody wants this, and can unfortunately lead to higher costs and very unhappy clients.\n\nFormulating Your Plan of Action\n\nWe now have the inputs we need to build our action plan around. Firstly, let's start with our timescales to ensure we avoid a service blackout. The date we need to prioritise is the date where we lose access, and should build our plans around this as a cutoff. Ultimately everything from our side should be in place by this point 👌. Here we should finish up any important outstanding work, ensure everything has been synchronised to the system (if you are working with exported data) and issue a SELF-IMPOSED directive to STOP USING THE SYSTEM. Don't go down to the wire, give yourself some breathing room so you can control activity. We want to ensure that NO WORK is carried out on the old system version AFTER any snapshots have taken place, as this work will be lost following the migration. This is because the new version will be built from these snapshots, so they MUST contain all your work.\n\nNext we shall discuss dependencies. These should be considered and accounted for by the date of migration, and the movement and/or special configuration(s) should be in place (or ready to go) for when the migration takes place. In an ideal world, the system and its configuration would undergo robust testing in temporary virtual environments prior to the full deployment to ensure everything is working correctly by your "go live" date. Otherwise, some kind of testing should have taken place so that we can have confidence that everything will work on the new network.\n\nConstruction worker building our system in accordance with our plan\n\nOur users should have been accounted for, written down and submitted to the migration team as early as humanly possible before the loss of access date. This gives them as much time as possible to ensure all users have access when the system is migrated. This might mean that logins will change slightly, so you should bare the potential requirement of secure credential deployment and management within any plan which you are creating. You should also utilise this user list to REGULARLY communicate your plan, project status, any required user actions as well as provide timely reminders to ensure as smooth a transition as possible.\n\nAny "special" configuration(s) should be investigated THE MOMENT any migration is announced. This may require some Sherlock Holmes level clue hunting if documentation isn't readily available (this shouldn't be the case but we do all live in the real world) to determine everything. This should be an ongoing process and all findings should be communicated back to the migration team. Do NOT go into any migration thinking this doesn't apply to you, or that everything will be okay in the end. The only reason why things (eventually) work is because of people who consider the issues and feed them back into a plan. Be part of the solution, or you will likely experience downtime.\n\nFinally, any plan should be built around your IT capabilities. Get them involved early and understand their expertise, their experience, their resourcing and ability to help within your required timescales. If the team are migrating many systems, understand the level of support you will receive and build your plan around that. Also use this insight for managing your user and client expectations to avoid future frustrations, and do not say nothing expecting everything will be okay. It won't be okay, issues will likely arise and people will be more annoyed if you wait the the inevitable issues to come before saying anything. Get ahead of the game based on the capabilities at your disposal.\n\nLady happy and relaxing after a successful software migration\n\nContinuous Improvement\n\nA good old fashioned migration is a great opportunity to improve documentation around your system(s), especially as you'll be gathering information to ensure that it goes as smoothly as possible. Whilst you are collecting what you need, try compiling it so into official documentation as you go along and issue that to your migration team. This way you can also keep it and officially publish it for future tasks. You may not need another migration, but the information will likely come in handy again and it would be a complete waste to have to repeat the gathering process.\n\nHere are some things you can do to continuously improve during your migration.\n\nCompile your user list and subsequently keep it up to date as users come and go. Make this list accessible so others can help and bake it into your team processes.\n\nPublish your documentation to your organisation's central repository and add the appropriate metadata to ensure it can be easily found in the future.\n\nRegularly review your "special" configuration(s) to determine if any simplifications can be made based on lessons learned.\n\nCentralise your communication and collaboration (rather than leave in private channels like email) so that others can understand and learn from the approach taken.\n\nSuccessfully migrating a system locally 😎!\n\nConclusion: Getting Things Right\n\nGetting a software migration correct is very important for mission-critical business processes. In order to help the process along, project teams should consider a selection of key elements when formulating a plan and providing assistance to the migration team. This plan should be clearly and regularly communicated to all applicable stakeholders, and expectations should be properly managed to avoid unnecessary frustrations. A successful migration is a collaborative effort, and the more effective this collaboration, the smoother the process will be.\n\nTake care and all the best, Si.