Documenting an SSIS Lift and Shift Project

I was honored to work on a cool SSIS lift and shift project in 2021. I will not mention project details or the client. I will share that I’ve worked with the team before and that they are awesome and talented and easy to work for (and with). The company is large. Like international-large.

I, Engineer

Many engineers are gifted communicators who are able to express themselves when speaking with non-engineers – especially directors and C-levels (CEOs, CIOs, CFOs, etc.) – in business terms. My good friends Nick and Frank are engineers with this gift, and I so envy them. I feel woefully unqualified in pre-sales meetings. Nick tells me I’m better at sales than I realize. I love Nick but I respectfully disagree.

For example, when I was on the initial project call with this client and they described the problem they were trying to solve, my response was along the lines of, “Not only have I never done this before, I do not know anyone who has!” They hired me anyway. In fact, the person with whom I spoke said something akin to, “We have confidence in you. We believe if you cannot do this, then it cannot be done.”

That was a cool confidence-booster.

tl;dr

I joined the team.
We did it.
It was fun, even.

Documentation++

We worked as a distributed team. If memory serves, all team members were located in the United States, even though it’s a global enterprise.

The actual work took months. Granted, I made notes along the way. But when it came time to produce written documentation, I realized my notes were woefully inadequate. I read some of them and said – out loud, although I was the only person in my office at the time – “Who wrote this crap?” I said that to my own notes.

About half my notes were stream-of-consciousness scribbles.

Microsoft Teams to the Rescue

Thankfully, our meetings were managed using Microsoft Teams. Even though we were online with each other, we shared a lot in writing via Teams chat. When I started the document, the first thing I did was create Appendix A and populate it with several chat histories. Appendix A is over 50 pages.

At the top of the documentation, I include a blurb to indicate the nature and format of the document:

(click to enlarge)
(click to enlarge)

From there, I share the story of this project starting with a non-technical description, followed by technical details, and including links to the relevant chat histories stored in the 50+ pages of Appendix A.

Could I have simply linked to Teams chat histories? Maybe. I want this document to live for the next decade or so, even though it will be outdated before I complete it. I am not sure how long Teams is configured to maintain chat histories, while I am confident Word will maintain these copies indefinitely. Plus, permissions.

I expect the document to exceed 100 pages total. I joked with my client: “This is what you get for hiring a writer!”

:{>

Need Help Lifting and Shifting SSIS?

Enterprise Data & Analytics is here to help with training, consulting, and concierge services!

Sign Up for my Newsletter

Want to keep up with my awesome blog posts? And the other stuff I write? Sign up for my newsletter today! It’s delivered to your favorite inbox like clockwork… every 2-6 weeks. ;{>

Andy Leonard

andyleonard.blog

Christian, husband, dad, grandpa, Data Philosopher, Data Engineer, Azure Data Factory, SSIS, and Biml guy. I was cloud before cloud was cool. :{>

Comments

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.