Maryland's new insurance portal starts with an empty history. Three clauses to put in your own portal contract

What Maryland told carriers

The Maryland Insurance Administration, the state's insurance regulator, is replacing the portal insurance carriers use for complaint filings, appeals and grievances. Its notice to carriers is short and clear. The current Licensee Portal goes dark at close of business on November 15, 2026. The new one, built on Salesforce with Box for file storage, opens on November 16. Form and rate filings, which go through a separate national system called SERFF, aren't affected.

One line in the notice carries most of the weight: closed task history won't carry over. The new portal starts with a fresh task list. Carriers are asked to download any records and correspondence they want to keep, try to close open tasks before the cutoff, and ask their IT teams to allow *.salesforce.com and *.box.com on port 443, by domain rather than by IP address. After launch, MIA staff will move some task items over by hand and follow up on anything that was open. Questions about old cases go to the carrier's MIA contact.

If you're a carrier, that's your checklist, and the dates are close. This note is for a different reader: the agency on the other side of a portal replacement. Maryland's notice doesn't say why closed tasks are staying behind, and we won't guess. But it's a good example of a decision every portal replacement makes. What moves to the new system is a contract decision, whether or not anyone writes it down.

Why this is a buying decision

When an agency replaces a portal that outside organizations use, there are two sets of records in play. There's the agency's own case file, which usually lives on somewhere. And there's what outside users could see and download through the portal: their submissions, the agency's replies, the status history. That second set is the one that tends to get dropped, because migrating it is fiddly, it's rarely in the original scope, and nobody inside the agency uses it.

The people who do use it are the companies filing with you. A carrier's compliance team may need last year's complaint history for an audit, or a lawyer may need the dates of a grievance. If the new portal starts empty, those requests come back to agency staff by email, one at a time, for years.

Neither choice is wrong. Starting fresh can be the sensible call when old data is messy or the cost of migrating it is high. The problem is making that choice late, after the contract's signed and the budget's spent, when it's no longer a choice. We wrote about a different agency that chose the other way, carrying applications in flight into its new system. Both are reasonable if they're decided early. Three clauses make sure they are.

Clause one: name the history that migrates

Write down, in the statement of work, which records move to the new portal and in what form. Be specific about the categories: open items, closed items, attachments, messages, status history, and how far back. If the answer is "open items only," say so, and say who builds the export that outside users will need instead.

Include the less obvious pieces: who sent each message, which notes the outside user could see, and the dates a case changed status. Those details are usually what an outside user is looking for when they come back a year later.

Ask the vendor to price both options during the bid: full history migrated, and open items only with a downloadable archive. Seeing the difference in cost turns a technical decision into a budget one that leadership can actually make.

Clause two: decide how outside users reach old records

If history doesn't migrate, outside users still need a way to get it. Options range from a read-only archive of the old portal for a set period, to a bulk export each organization can download before cutover, to a request process through agency staff. Each has a cost and a staffing implication.

Put the chosen option in the contract with a duration. "Read-only access to the legacy portal for twelve months after go-live" is a clause. "We'll figure something out" is a future workload for your complaints team. Make sure the export, if that's the route, includes attachments and messages, not just a list of case numbers.

Clause three: require notice and network support for outside users

Maryland's notice did several things well. It gave carriers dates, listed the exact domains and port to allow, explained why to allow by domain name, and named a support address for access problems separate from the complaints staff. Each of those had to come from someone who knew the vendor's platform.

Write that into the contract: the vendor provides the network requirements, a draft notice for outside users, and a support channel for access issues during the first weeks. Set the notice period too. Large outside organizations route firewall changes through their own IT queues, and a few weeks can be tight. A one-page cutover plan that includes the outside users, not just the agency's own staff, is the simplest way to make sure nobody's forgotten.

If you're a carrier reading this

The Maryland dates are real and close, so here's the carrier version in one place. Before close of business on November 15, have someone download what your team may need later: complaint and grievance correspondence, attachments and any status history for closed matters, organized so you can find them by case. Work through open tasks that need your action and close what you can. Send your IT team the two domains, *.salesforce.com and *.box.com on port 443, and point out that the MIA asks for an allowlist by domain rather than IP address.

On November 16, sign in to the new portal at the address in the MIA notice and confirm that the people who handle complaints can reach it from their usual network. Watch for MIA staff following up on tasks that were open at the switch. And keep the downloads somewhere your successor will find them, because the regulator's notice says that history won't be in the new system.

If your agency is planning a portal replacement and wants help writing the requirements, comparing vendor bids or planning the cutover for outside users, our government and public sector team does that work. Get in touch before the RFP goes out.

Related work: Sutton Place.