Oregon's land agency won't make anyone reapply when its new portal opens. Plan your applications in flight the same way

The promise worth copying

On December 7, Oregon's Department of State Lands (DSL) launches DSLConnect, a public customer portal for the people who apply to the agency for wetland and waterway permits, dock registrations, waterway leases and easements. It replaces the Land Administration System, which DSL has used for more than 25 years and which never had a public web portal at all. DSLConnect sits inside a new back-office system DSL calls OWLS.

Most of the announcement is what you'd expect: online payments, free accounts, no pre-registration, a WCAG 2.1 AA accessibility target, guides and walkthroughs before launch, a support team after. And an honest warning that some services, including permit processing, may be slower during the transition.

One answer in the FAQ stands out. Asked whether people who already submitted a permit application need to reapply in the new portal, DSL says no: applications that haven't been fully processed will be automatically uploaded to DSLConnect. Paper and phone stay available too, for anyone who'd rather not use the portal.

That sounds like a small line. For anyone replacing a public system, it's the hardest promise to keep. The people who notice a system change first are the ones who were halfway through it.

Case file one: the application waiting on a reviewer

Here are three made-up cases, of the kind any permitting agency has in its queue the week before a switch-over. They're composites, not DSL cases.

A contractor applied in October to place fill near a creek for a small bridge. The application is complete and waiting for a reviewer. Nothing about it is unusual.

What has to move: the application itself, every attachment, the fee payment record, the date it was received (because review clocks often run from that date) and the reviewer it was assigned to. What tends to go wrong: the attachments come across but lose their labels, the received date becomes the migration date, or the assignment is dropped and the case sits unowned.

The question for a vendor: show us this case, before and after, on our own data, and show us the received date. Then ask what the contractor sees. If they log in to the new portal on December 8, is their application there with the right status, or do they have to call to find out it exists? The answer tells you whether the vendor has thought about the applicant, or only about the database.

Case file two: the paper application with a phone history

A retired couple renewing a dock registration mailed in a paper form. Staff keyed it in, then called twice to ask about a missing drawing. The drawing is on the way by mail.

What has to move: the keyed-in data, the scanned form, notes from both calls and a flag saying "waiting on applicant." The new portal also creates something new: an online account the couple may never open. If the system expects every customer to sign in, this case falls through.

DSL keeps paper and phone available after launch, which is exactly right. The question for a vendor: how does a case with no online account get updates, and how do staff see the call notes from before the switch?

Case file three: the case that's almost done

A marina operator's waterway lease amendment has been approved. The final document is being drafted, and the invoice hasn't gone out.

What has to move: the decision, the draft, the billing status and the conditions attached to the approval. What tends to go wrong: "approved but not issued" doesn't exist as a status in the new system, so the case gets mapped to "under review" and the operator gets a confusing email asking for information they already gave.

The question for a vendor: list every status in the old system, show us what each one becomes, and tell us which ones have no match.

This is the case file most migration plans miss, because it looks finished. In an old system that's been in use for decades, statuses pile up: some were added for one program, some mean different things to different teams and a few nobody can explain. An hour with your longest-serving staff member and a printout of every status will save weeks of confused applicants later.

What to put in the contract

If you're an agency buying a replacement system, these cases turn into a short list of requirements worth writing down before you sign:

• No reapplying. Every case that's open on cutover day moves across, with attachments, dates, payments and history.
• Original dates are kept. Received dates, review clocks and deadlines carry over unchanged.
• Every status is mapped. Old statuses map to new ones, and the gaps are resolved before go-live, not after.
• Non-digital customers are covered. Paper and phone cases keep working, and staff can see their history.
• A dress rehearsal on real cases. Migrate a copy of the live queue, then have staff check a sample case by case.
• Applicants hear one clear message. Tell people in flight what will change for them, and what won't, before the switch.

DSL also plans dedicated onboarding for current customers and says some application information will be viewable online without a public records request. Both are worth copying: the first lowers support calls in the first month, the second answers the question people call about most often, which is "where is my application?"

Be honest about delays, too. DSL tells customers up front that processing may slow down during testing and transition. Saying that early costs nothing, and it turns the inevitable slow weeks into something people were warned about rather than a complaint.

Before you pick a date

We've written before about putting the cutover on one page before a freeze. For a public agency the same page needs a line for open cases: how many there are, who checks them after migration and how applicants are told.

Pick your three hardest real cases, the ones like these, and make them the test every vendor has to pass. If you'd like help writing those requirements or planning the migration, our government and public sector team works on exactly that. Talk to us.

Related work: Sutton Place.