The Hand-off document should be something you can link into your project web site, as well as something you can email to your client. You will be responsible for leaving your client with a working system in some environment that the client controls. This document describes how to make that happen.
Think of the hand-off document as a "design document light". It won't be heavy on technical detail but it is not a user manual either. It must have enough techie stuff in it to allow your non-techie client to launch your good work into action.
You should describe (to the client, but I will read it) how to obtain your work in a form that gives the client the value they want. This means a pointer to a github repo is not good enough. You need to provide a step-by-step process the client can follow to get the system set up and executing.
Also include in this document a brief description of what the system is technically. Is it a Carolina CloudApp? If so, where is it located, and who owns it... and how can the client come to own it? Is it a stand-alone program the must be copied to some local machine and compiled? If so, how do the client copy it and how does the client compile it? Is it a web application that will need a host that the client must provide? If so, how can that be set up?
Discuss any issues you can think of with your client in advance. If the client will need to find a host machine for your work, make sure they know this and have some plan in mind.
It is worth repeating what we said up top... you will be responsible for leaving your client with a working system in some environment that the client controls. This document describes how to make that happen. So think through it in detail now, before crunch time.
You may wish to make sure of a solid hand-off by setting up a hand-off appointment with your client at the end of the semester. Then you can in-person install (in whatever way is necessary) the project into their environment and make sure they have it running properly.