GitHub Classroom Is Shutting Down: What to Do Before August 28

If you run a programming course on GitHub Classroom, your fall semester just acquired a dependency risk. GitHub is retiring the product, and there are two dates on the calendar rather than one. The second is the one that catches people out.

A disclosure before anything else: Coder in 90 builds one of the replacement products discussed at the end of this post. Almost everything in this checklist is portable work that applies whichever replacement you choose, and the steps that matter most are the ones you do inside your own GitHub organization, where nobody can charge you rent for them.

What is happening and the two dates that matter

GitHub announced the deprecation in a community discussion thread, which remains the primary source worth reading in full and re-checking for edits: github.com/orgs/community/discussions/196615.

The two dates, as published in that thread as of July 2026:

August 28, 2026. GitHub Classroom stops operating. Assignment invitation links, roster management, the autograding integration, and the Classroom web interface go away.
September 4, 2026. Classroom data is deleted. This is a week after the shutdown, and it is the deadline that actually governs your exports.

The gap between the two is your entire grace period. Anything that lives only inside GitHub Classroom and is not exported before September 4 is gone. For most northern hemisphere instructors this lands directly on top of fall term setup, which is why the work below is sequenced to be finishable in a couple of focused afternoons rather than a semester of planning.

If you teach on a January start, you have more slack in the calendar but exactly the same September 4 export deadline. Do the exports now regardless of when you next teach.

What you keep and what you lose

The good news is that GitHub Classroom was always a thin layer over primitives you already own.

What you keep, because it lives in your GitHub organization:

Every student repository, with full commit history, branches, and pull requests.
Your assignment template repositories.
Any GitHub Actions workflow files committed inside those repositories.
Your organization membership and teams.

What you lose when Classroom goes:

Rosters, including the mapping from a student identifier to a GitHub username. This mapping is the single most annoying thing to reconstruct by hand, and it is the reason to export first and think later.
Assignment configuration: deadlines, invitation links, per-assignment settings, visibility, and starter code associations.
Grades and autograding results held in the Classroom gradebook rather than in your own institutional gradebook.
The Classroom autograding configuration, which was stored as Classroom metadata rather than as a workflow file in the repository.

Read that list twice. The repositories, the code, and the history are safe. The coordination layer is what evaporates, and coordination is exactly what a replacement has to give you back.

Step 1: Export rosters and grades before September 4

Do this first, before you evaluate a single replacement product. Exporting takes under an hour and it is irreversible if you miss the window.

For each classroom you have ever created, not just the current term:

Download the roster as CSV. You want the student identifier, the linked GitHub username, and the repository name for every assignment.
Download the grades or assignment results export for each assignment.
Save the list of assignment names, their template repository URLs, and their deadlines. If there is no export for this, a screenshot of the assignment list is better than nothing.
Put all of it in a private repository in your organization, or in your institution's storage, with a README naming the term and the course. Future you will not remember what export-3.csv was.

One detail worth checking: past terms count. Departments routinely get asked to substantiate a grade from two years ago, and after September 4 the only evidence you will have is whatever you exported.

Step 2: Inventory what your course depends on

Now write down what your course actually needs, rather than what your current tool happens to do. A short honest inventory prevents you from buying a large platform to replace three features.

Work through these:

Assignments. How many per term, individual or group, and how much starter code does each carry?
Autograding. Which assignments are automatically graded, what runs the tests, and how long does a test run take? Note whether the grade is the test result or whether a human adjusts it.
Deadlines. Are they enforced by locking repositories, by timestamp inspection, or by trust? Do you grant extensions, and how often?
Teaching assistants. How many, and how do submissions get distributed among them? If you currently do this in a spreadsheet, say so.
Feedback. Where do students receive it: pull request comments, issues, an LMS, or office hours?
Integrations. Does anything sync to Canvas, Moodle, Blackboard, or a campus gradebook?

The inventory usually reveals that two or three items are load bearing and the rest is habit. That is the point.

Step 3: Choose a replacement

Judge candidates against the inventory, not against a feature list. The criteria that matter for most courses:

Hosted or self-hosted. Free and open source options exist, and they are genuinely good, but somebody has to run the server and be on call when it breaks in week three. Decide honestly whether that person exists in your department.
Cost model. Per student per semester and per instructor per month produce very different bills at 30 students and at 300.
Real Git workflow or a browser sandbox. If part of your learning outcome is that students can use branches, commits, and pull requests, a managed sandbox works against you.
Feedback quality. A red X tells a struggling student that they failed, not why.
Exit cost. Ask what you take with you if you leave in a year.

The candidates worth a look are Codio, Classroom 50, CodeGrade, Classmoji, and our own product. The option GitHub itself pointed at is Codio, which publishes its list pricing at codio.com/pricing; our head to head against it is at /codio-alternative/. Pricing for our plans is at /pricing/.

Step 4: Rebuild autograding on GitHub Actions

This is the step that buys you independence, and you should do it regardless of which product you pick.

Classroom's autograding was configured in Classroom. A standard GitHub Actions workflow, committed as .github/workflows/autograde.yml inside your assignment template repository, does the same job and belongs to you. When a student pushes, the workflow runs the test suite in your organization's Actions minutes and reports the result.

Three practical notes. Keep the workflow in the template repository so every generated student repository inherits it. Have it emit a machine readable summary, such as a JSON file of test names and pass or fail, so that any grading layer you adopt later can read the same output. And make the workflow runnable locally with a single command, because a student who can reproduce the grader on their laptop stops filing tickets.

Here is the honest paragraph about our own product, since this is the section where it is relevant. Coder in 90 Classroom is a hosted layer over exactly this arrangement: plain GitHub template repositories and a standard Actions autograde workflow in your own organization. What it adds is an AI mentor that reads the failing test output and explains why the test failed, grounded in your own course notes, and posts that explanation as a pull request review comment or a repository issue. The real test output is always shown alongside the explanation, so a student never gets a confident paragraph in place of the evidence. Because the repositories and the workflow are ordinary GitHub objects, turning us off leaves your course running.

Step 5: Dry-run one assignment end to end before fall

Do not migrate a whole course on faith. Pick your simplest assignment and run it start to finish with a throwaway student account:

Create the assignment from your template repository.
Accept it as the test student and confirm the repository is created with the starter code and the workflow.
Push a deliberately failing commit. Confirm the autograder runs and reports a failure, and read the feedback exactly as a student would see it.
Push a passing commit. Confirm the result flips and lands wherever you expect grades to land.
Let the deadline pass. Confirm locking or late handling behaves the way you told students it would.
Export the results and confirm the format matches what your campus gradebook wants.

Any replacement that survives that rehearsal will survive September. Any that does not has just saved you a very bad first week.

A working-backwards timeline for the fall semester

Counting backwards from a late August or early September term start:

By August 10. Exports complete and stored. Inventory written.
By August 17. Replacement chosen, trial account created, one assignment template converted to a plain GitHub Actions autograde workflow.
By August 24. Full dry run finished. Roster imported from your CSV export. Teaching assistants have access and know the review process.
By August 28. GitHub Classroom shutdown. Nothing you rely on should still be running there.
By September 4. Data deletion. Final chance to grab anything missed. Verify your exports open correctly rather than assuming they do.
Week one of term. Run the first real assignment with the smallest possible stakes so that any surprise costs a participation point rather than a grade.

The migration is a smaller job than it looks, as long as you start with the exports. Everything else can be rebuilt from a template repository and a workflow file. Rosters cannot.