<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Im a bit late to the party here, but seeing as I am currently in the midst of a migration from on premises services into AWS I figure I can at least provide some pointers to expand on Johns point.<div class=""><br class=""></div><div class="">The work I am doing is largely non transformative, that is to say that we are not taking services and splitting them up to be AWS native. However, we are utilising AWS tooling where it makes sense to do so.</div><div class=""><br class=""></div><div class="">First thing is not to think of the numbers of servers you are tasked to migrate. You have a number of services that you need to migrate, which will be made up of a number of servers. Your goal should be to migrate the service, not the server. Lifting and shifting servers into AWS is a great way to spend loads of cash and pile on more technical debt to your exiting debt without addressing any already existing.</div><div class=""><br class=""></div><div class="">My current task, that I am just code complete on this week was to migrate a server that ran about 20 odd bash scripts in cron jobs. Rather than lift and shift we decided that it would be better to build out a terraform module to allow is to manage scheduled tasks in Fargate and Event Bridge. This way we get our cron jobs, they only cost us when they’re actually running and we also get the option of introduction event driven “cron” tasks later. This is all very nice and shiny. I started that around May and we are only now in the endgame of testing.</div><div class=""><br class=""></div><div class="">Why did it take so long?</div><div class=""><br class=""></div><div class="">1) Discovery took ALOT longer than initially expected </div><div class="">2) We didn’t have a method of executing scheduled tasks in Fargate and Event Bridge, so that had to be built.</div><div class="">3) We are reliant on some 3rd parties to do stuff like firewall changes and sending us files that the cron jobs consume.</div><div class=""><br class=""></div><div class="">By far the most difficult part of this task has been the discovery phase. Of the initial 5 days slated for discovery I have probably used at least double that if not more on just understanding what the system currently runs, what it interacts with, who owns which cron job, if that cron job is even required anymore etc. </div><div class=""><br class=""></div><div class="">Sure its taken several times the timescale you have, but from a business point of view its a win:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- From the original 20 odd tasks I am migrating half a dozen.</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- We now have a scalable and simple solution for others to add scheduled tasks with 10 lines of terraform in their module</div><div class=""> - The solution costs practically nothing to run.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">You are being asked to eat an elephant, and if you just start biting chunks you’re going to throw up. If I were you I would tackle your problem in roughly the following way.</div><div class=""><br class=""></div><div class="">Group the servers into services and identify the stake holders.</div><div class="">Get a broad idea of what the service does (is it a mail server? is it a web service? is it a proton accelerator?)</div><div class="">Perform an initial discovery by logging into the server(s) and poking around. Document how you think the service works.</div><div class="">Interview the stakeholders and make sure that your understanding is correct and what the business impact of the server is.</div><div class=""><br class=""></div><div class="">At this point you should have enough information to architect the AWS Solution and a migration plan. Only at this point will you be in a position to estimate how much time the actual migration work will take.</div><div class=""><br class=""></div><div class="">For a single or dual server service that is about 3-5 days work. For anything bigger add a day per server as a finger in the air. (Even those estimates assume the service is fairly simple and all managed by Ansible or Puppet or something sensible).</div><div class=""><br class=""></div><div class="">Some simple maths to round off, assuming every server is an isolated service:</div><div class="">10 weeks is 50 days. </div><div class="">40 servers @ 3 days per server for discovery is 120 days.</div><div class="">So you are already at 24 working weeks of discovery in the best case.</div><div class=""><br class=""></div><div class="">You need to have a sit down with your PM and come up with some realistic expectations for scoping out the work first.</div><div class=""><br class=""></div><div class="">Hope the wall of text helps in some way.</div><div class=""><br class=""></div><div class="">Callum</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 19 Jul 2021, at 20:40, John Dow <<a href="mailto:jmd@nelefa.org" class="">jmd@nelefa.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div dir="ltr" class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><br class=""><div dir="ltr" class=""><br class=""><blockquote type="cite" class="">On 19 Jul 2021, at 19:33, Martin Love <<a href="mailto:martin.t.love@gmail.com" class="">martin.t.love@gmail.com</a>> wrote:<br class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class=""><p class="">Hi Tahir,<br class="">
<br class="">
The first think I would be doing is setting expectations with the
Project Manager. </p></div></blockquote><div class=""><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class="">This, above all else. A project like this needs to be clearly defined if it’s to succeed, and that’s the project manager’s job, not yours. </span></font></div><div class=""><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font></div><div class=""><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class="">The timescales you mentioned are completely unrealistic for essentially reimplementing the services provided by the machines.</span></font></div><div class=""><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font></div><div class=""><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class="">Additionally, the “seems to” in your question suggests that you’re not 100% clear on what it is they actually want. When you say “migrate from one organisation to another organisation”, what do you mean? </span></font></div><div class=""><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class=""></span></font></div><div class=""><font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class="">John</span></font></div><div class=""></div></div></div>-- <br class="">EdLUG mailing list<br class=""><a href="mailto:EdLUG@mailman.lug.org.uk" class="">EdLUG@mailman.lug.org.uk</a><br class="">https://lists.edlug.org.uk/mailman/listinfo/edlug</div></blockquote></div><br class=""></div></body></html>