CourseInfo Blackboard: a night the name changed

Introduction

The first task was unglamorous: find every place the software printed its own name. About dialog boxes. Installer banners. The text that appeared on first login. The readme file we shipped by habit and the headers in exported gradebooks no one read until a dean asked. We had a list on a whiteboard, numbers in the left column, initials in the right, and a pile of late-night coffee in the middle. The goal was mechanical and strict: change CourseInfo to Blackboard everywhere the user could see it, leave everything that made their courses work exactly as it already did.

That night sat between two facts we had already lived. In 1997, CourseInfo LLC formed in Ithaca, New York, built in and around Cornell University by a small team trying to make the web usable for teaching. The same year, Blackboard LLC formed in Washington, D.C., focused on bringing online learning into institutions at a level presidents and provosts could commit to. In 1998, we merged those tracks and created Blackboard Inc. The press language would talk about leadership and alignment. The room we were in talked about build numbers, domain names, support lines, and contract riders. We were pointing two beams at the same wall and trying to make one line.

The operational reality was simple and demanding. Courses had to open Monday morning regardless of what hit the newswires. Faculty who had learned how to post assignments on Friday should not need a retraining session on Tuesday. Procurement officers who had negotiated with CourseInfo the previous quarter still needed their invoices to match purchase orders and their auditors to see a clean file. The renaming could not become a system interruption. It had to feel like continuity.

> The only heroism anyone wanted was the kind you see in a systems log where the timestamps line up.

We worked from checklists because checklists survive fatigue. One for product artifacts. One for web and DNS. One for contracts and billing. One for communications. We had owners on each list, and a rule to only mark an item if two people saw it and initialed in different ink colors. It sounds fussy now; it was ballast then.

Cornell to Washington handoff

The work that led to that night did not start with a name. It started with students and faculty trying to get a first course website to load without someone hand-coding HTML in a lab after midnight. CourseInfo, in 1997, was a set of scripts and a simple interface meant to help an instructor build a presence on the web with the parts that mattered: announcements, files, a gradebook, a way to reach students. We made it administrable so an IT staffer could support a department without crawling under desks. We made it tolerable on the networks that actually existed on campuses at the time.

The same year, in Washington, Mike Chasen and Matt Pittinsky set up Blackboard LLC to work at the layer where institutions had to make decisions: frameworks, standards, procurement, and narratives a president could stand behind. Where we were learning which buttons instructors would press on a Sunday night, they were learning what a system needed to look like to pass a committee on a Wednesday afternoon.

Lesson — A market category forms when practical tools merge with an institutional narrative.

It was not obvious on day one that these efforts would join, but on the ground the paths converged. CourseInfo learned to speak in terms an RFP could parse, while Blackboard learned where the product had to hug the contours of actual classrooms. That is how categories form: the practical merges with the presentable until it stops being a debate and starts being a procurement line. Universities wanted a platform faculty would adopt without force, and a contract the institution could honor over years.

By mid-1998, the decision to merge was not a leap; it was a response. We formed Blackboard Inc., carrying forward the name that institutions were already repeating in meetings and that we believed could hold a wider category. CourseInfo did not disappear; it became a product line inside a broader entity and a combined team. The brand needed to match the scale of the commitment we were now asking from campuses.

The merger decision and the name

Names become real when they appear on contracts and screens. Before either, they have to pass a simpler test: the team has to be able to say the word for a week without stumbling. Inside our rooms the debate had already quieted. Blackboard traveled better across an institution. It signaled an idea administrators recognized immediately; it felt like a place where teaching happened, not just a piece of software. CourseInfo described a component of that place. We needed the larger anchor.

There were other considerations that were not romantic and mattered more. Trademark searches had to come back clean in the classes we expected to touch. The domain had to be defensible. The new company needed to match filings we could make and defend on a fast schedule. We had corporate counsel ready with draft language, state filings queued, and letterhead templates waiting for a final decision on capitalization and spacing.

Once the decision was made at the board and founder level, the hard part was downstream. Software does not care what a team believes. It cares what string is in a variable and which build number increments when you compile. That night was where intentions met the friction of real systems. We planned for it as we would any release: freeze the build, stage the changes, test on the machines people were actually using.

The checklist on the table

Lesson — Translate strategic decisions into operational checklists to ensure execution survives fatigue.

A high-level decision to rename a company means nothing until it is broken down into concrete, verifiable tasks. We used checklists to turn our intention into action items that could be managed under pressure and late-night exhaustion. Each list had clear owners and a strict verification rule—two sets of initials in different colors—to ensure nothing was missed. This wasn't about bureaucracy; it was about building ballast against human error.

> We worked from checklists because checklists survive fatigue.

The first checklist covered code and visible product elements. We listed every artifact that carried the name CourseInfo:

Splash screens and login headers.
About boxes and version dialogs.
Installer banners and license text.
Readme files and change logs.
Default email templates for password resets and account creation.
Exported gradebook headers and footers.
Screen-captured images inside training decks.

Each line had a path or a reference. The rule was: the thing a faculty member sees on first impression says Blackboard; the specific product module, where needed, can retain the historical CourseInfo name to prevent confusion in support scripts. We rebuilt installers and tested on a lab of machines that mirrored our customers' campus hardware. The build stamp changed; the behavior did not.

The second checklist covered web and DNS. We had lowered TTLs two days prior to make the cutover propagate faster. The plan was staged redirects from courseinfo.com pages to their counterparts on blackboard.com, with logs enabled so we could watch what people actually clicked. We kept a parallel site under the old domain with a prominent banner for a short, defined window.

The third checklist was contracts and billing. We prepared standard notices of assignment. The orders did not change; the entity on the invoice did. Pricing, service level language, and renewal dates stayed the same. We double-checked that our tax identification and remittance details were correct on new templates.

The fourth checklist was communications. Customers read messages before they read marketing. We drafted a plain-language email, with versions for administrators, IT staff, and faculty. We also queued a press release for the morning, stating the intent and reasons for the merger. It spoke to systems and categories; it did not ask faculty to do anything.

Changing the product without breaking it

Lesson — Treat a name change like any other feature by mapping all its downstream dependencies.

Product changes at a name layer seem low risk until you count all the places a name functions as a signal. A login page change means screenshots in help docs change, which means a help desk workflow changes, which means a campus trainer’s slides change. We organized these dependencies like any other feature—by surfacing them, owning them, and giving them a date.

Support scripts were reprinted and redistributed, with small edits like “When you see the Blackboard login” replacing “When you see the CourseInfo login.” These are not cosmetic; they are operational. The speed with which a support person can map a caller’s description to the right action is the difference between a fix and a second call tomorrow. We set up a short internal crib sheet of changed phrases for anyone who talked to customers.

For training materials, we reshot key screens under the new name and updated the captions. We did not rewrite the entire manual overnight; we replaced only those images and labels that would cause a mismatch in a class the next day. The rule was simple: what appears in the first 15 minutes of a standard training gets updated now.

On the technical side, we were careful with logs and audit trails. Where CourseInfo appeared as an internal string in audit output, we left it alone for now and documented the point of change. History in a log file is not brand language; it is the factual record of what the system did.

Communicating the change

Lesson — Prioritize operational clarity over marketing language in all customer communications.

Institutions do not make decisions on adjectives; they do it on whether they can continue to meet their obligations. Our communications plan was designed to project stability and continuity, not hype. The subject lines were factual, the first paragraph said what was changing (the company name), and the second said what was not (their service, data, and contacts). We provided a simple crosswalk guide so administrators could easily map the old name to the new in their own documentation.

> The moment when a person is trying to fix a small problem is the worst time to teach them a new word.

The calendar for the night was structured backward from two moments the next day: when a faculty member logged in and when an administrator’s inbox loaded. We sent the customer email before the press release, staged to hit inboxes early. Support was not a separate department that night; it was the room. If someone called with a problem, the person who owned the line item in the checklist could pick up.

We kept the tone plain. We promised to follow up with any campus that saw confusion and then kept that promise. We measured the change like a systems operator would, watching redirect logs and support tickets. We did not congratulate ourselves when a tweet landed; we did it when no one noticed the cutover who did not need to.

Paperwork and the back office

The surface of a company is what the outside sees; underneath is the accounting of how it works. The night the name changed we made sure that the inside could record the outside without contradiction. That meant:

New invoice templates with Blackboard Inc. and correct remittance details.
Updated W-9 and any tax forms customers would request on renewal.
Bank accounts prepared for wires under the new name.
CRM records updated so that renewals, opportunities, and support contracts were consistently labeled.
A cadence for how we would rename folders and repositories so that, a year later, someone could find a contract from 1997 without guessing.

We did not try to rewrite all internal language in a night. We drew a date line—before and after—and documented where the two sets would meet. The test again was auditability. Could someone in finance, support, or legal reconstruct what happened and why without asking three people who left the company? If yes, we were done.

We also paid attention to sales operations. SKUs that salespeople used to create quotes needed to map cleanly to the new product names. A salesperson looking at a screen at 8 a.m. should not need a training session to find what they sold last week. We provided a one-page mapping: old name, new name, effective date, internal owner.

What changed and what did not

The line between a company and a product is porous on purpose. The night CourseInfo became Blackboard, the company that stood behind the contracts and the software changed its letterhead, its filings, and its website. The product that faculty used did not change its behavior. That was the principle and the promise.

We spelled out what changed so no one would over-read the moment:

The company name in contracts, invoices, and signatures.
The brand presented on login, installer banners, and public docs.
Where to find product information on the web.

We spelled out what did not:

Course data, permissions, and URLs already in campus LMS portals.
Support contacts, escalation paths, and service-level timings.
Pricing on quotes already delivered and renewals already under discussion.

We did not pretend nothing meaningful had happened. Two companies formed in 1997 had merged in 1998 and were now presenting as one entity. But we did not make the customer pay for our decision by having to do work we could do for them. Change is easier to accept when it arrives as continuity.

The small artifacts that carry trust

During the night, a pattern became obvious in a way only sustained work can show you. Trust rides on small artifacts. The support script that now reads “Blackboard” but still takes the caller to the same fix. The training deck with updated screenshots that match the interface a faculty member sees. The redirect that lands on the right page without an error.

> Trust rides on small artifacts.

We collected those artifacts with intention. We did not allow ourselves to assume that any single change would propagate through the organization by osmosis. Ownership was explicit. The person who updated the training deck also recorded the filename and where it would live. If this sounds like overkill, it is only because we are used to telling brand stories without reading the change logs.

The room had different disciplines in it—product, support, sales operations, finance—because no one group could see all the surfaces at once. Product saw the build system. Support saw the sentences that caused confusion. Sales ops saw the quotes that would fail. When you put them in a room with a single objective, you get a more complete picture of the work required and a cleaner morning.

The longer arc

We did not write history that night; we wrote release notes. But history sits inside those notes. The path from experimentation to category is made up of rooms like the one we were in. In 1997 we were at Cornell building something that made the web tolerable for teaching. In 1998 we were in a room making a brand that could carry what we had built into institutions at scale. In 2004 we put a ticker symbol—NASDAQ:BBBB—on years of decisions like the one we lived that night.

After the night, we kept moving. The product line that had been CourseInfo became Blackboard CourseInfo in naming and then, as the platform evolved, folded into releases that no longer needed the qualifier. We invested in an extension architecture that would later be known as Building Blocks, because institutions and partners needed to add to the platform without forking it. We grew the team to handle multiple releases a year without losing the operational memory that made nights like the rename quiet instead of loud.

The lesson that stayed with me was not about marketing. It was about staging risk and making change additive. You can rename a company and preserve your users’ mental models if you keep their work at the center. You can honor contracts and carry them forward without forcing a reset. You can change a logo and fail if you ignore the single screen a support person looks at most. The small choices are where the big claims become true or not. That is what companies, and categories, are made of.

The Night CourseInfo Became Blackboard