You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The idea for this series of articles came to me while deep in the throes of making the journey from my warm and friendly Server environment to the wispy world of the Clouds. I am the solitary admin referenced in the title.
I had originally thought this would be a single, longish article. However, as the journey progressed, material for such an article piled up and it was a pile. The earlier chuckle evoked when naively thinking that a single article would cover this journey now causes outright laughter. This is a Big Deal, Big Effort journey. Even these admittedly long winded articles only brush the surface.
In the preface to Episode 1, it was my aspiration that these monographs might help other humans thinking about this or making the journey. I hope they have and will continue to do so.
So, without further adieu....
As I write this closing episode, I am shutting down my Atlassian Server environment for the last time. I find myself somewhat wistful as some of my best systems work is embodied there.
Looking back at code commits for Dockerfiles, docker entrypoint scripts, AWS <insert thing here> JSON build files, big CTE SQL scripts, and bash scripts that enabled the sloth in me for my day-to-day, I see how far that world came. Shining like beacons are highlights such as when I could finally use Alpine Linux as my Docker image base because finally OpenJDK was supported and the increasingly complex SQL for the database used to help rationalize local users/groups in Atlassian tools to a central user authority. In my current “official” role, I am unlikely to be that deep in these things again but… never say never.
After <mumble> years in technology, I found myself on one of the longest vertical learning curves of my career that was as daunting as it was rewarding. My hope is that I learn some New Thing each day. This effort provided that via the proverbial fire hose.
As I commented in the penultimate episode, I have been exceedingly fortunate to have a user base as good as I have. Their forbearance (when needed), support, and humor certainly eased the painful bits.
As I started on this effort, I approached it as I always have; I have to be able to do <insert thing> 3 times perfectly in test before I do it in production.
That’s not a Thing for a hosted Atlassian to Atlassian Cloud migration.
As a good virtual friend who lives the Atlassian Life as I do, @Matt Doar, put it so eloquently:
“You reach the point where the desire for perfection is replaced with the desire for completion.”
Looking back, that conversation was a watershed moment. That isn’t to say I gave up on doing it right. Rather, I reached a “Don’t sweat the small stuff” state. In many ways, I think had I not reached that point, I would either still be a very long way from completion or I could have been looking at a massive failure of a major enterprise-wide project.
While, initially, the yellow “Migration Incomplete” lozenges for a migration task grated on my nerves, after that conversation I looked at what “incomplete” really meant. After fixing the things I could that showed up in the migration log, in all the cases, the bits I couldn’t fix were trivial or even utterly inconsequential.
The tendency, when looking at this new and pristine environment to which nobody has (yet) committed an engineering atrocity, is to move in shiny and clean. In this context… you can’t. Don’t even try. Can you make it better? Yes. Perfect? No.
As such, going back again to not being perfect: There was tech debt in the old system. Any environment that has been running for years has it but there was literally no way to make the migration and eradicate the tech debt as a happy coincidence. However, since I had to touch all the things to make the migration, but doing so in a (somewhat) thoughtful manner, I managed to reduce the tech debt or, at worst, swap some old tech debt with new and shiny tech debt. The Structure for my migration started to get “post-migration tasks” added which, now have migrated into the general stream as backlog items.
I had tech debt before. I have tech debt now. We move on.
Throughout this journey, I took the approach of tell all the people all the things all the time. Confluence pages. Company wide Slack messages. What was coming and (where possible) what was cool about it. Reminders that <insert thing> was starting <insert warning time period>. Status of <insert effort ongoing> all through the “ongoing” state. If it “felt” like a certain operation and maybe the outcome would be visibly rough to the users, tell them ahead of time. Doing UAT migrations on tranche by tranche basis and walking through the New World Order with the teams before they migrated in production so there were no shocks.
This was key as, while not everybody reads these, enough do who appreciate it and will organically help out when the human that didn’t “get the message” yells a “help I’ve fallen and I can’t get up” message, and leap in with guidance.
I set up a cloud migration help me help me Slack channel that was key for this and promoted it regularly I’ve now seen an interesting 2nd order effect of it being there. It has organically morphed into a company Atlassian User Group.
It used to be that if the “wait for it' spinner spun too long my jaw muscles would clench up. No longer. 4XX and 5XX errors are all a SEP (Someone Else’s Problem). App timeouts; also a SEP. It used to be when I’d see any of those I’d be off to get on the server, start tailing log files, and do all that administrator stuff. Now it just gently rolls over and past me because… SEP
The above heading perhaps overstates this a bit but it often felt like that. This chronicler had to touch literally every validator, condition, and post function in every workflow that wasn’t utterly default to make it work. The ways I used to make a Thing work either don’t exist, work vastly differently or, worse, exist but don’t work in that particular scenario. A lot of the admin is vastly different from Server. Aside from concepts of How To Do A Thing WIth Jira, almost all of the administration of the environment is somewhat to totally different. The one element that seems close but not totally the same is Automation.
“I laughed, I cried, It was better than Cats”
There were some very dark times. I spent a lot of time tired due to long haul weekend and overnight tranche migration efforts but here we are at the end of all things.
The migration cutovers ended up being largely non-events. The long effort of planning and testing before even a UAT migration, UAT reviews with teams before official cutover, and scoping migrations to fit a defined timeframe paid off. A given group of humans stopped working one evening on Server and started the next work day in Cloud. Aside from the inevitable “How the <insert expletive of your choice> do I <do a thing that can’t figure out how to do>” cries and a bare handful of escaped bugs, work moved on.
My user base is generally very happy with Cloud. Are there things we miss and/or are annoyed by both me and them? Yes. However, most of those are balanced by some element that is better than it was on Server. Now that we’re all moved in and it feels like “home”, everyone is content. A lovely coincident effect is, with the new world, the user base is charged up and looking at new, more, and better ways to employ these tools.
While I do, of course, have ongoing post-migration work to do that is directly related along with new and exciting tech debt to deal with, shutting down Jira Server and Confluence Server closes the books on the Migration proper.
Good bye, old friends. You have been steadfast and loyal companions.