Software evaluation and migration worksheet (example)

To decide whether to leave Trello for a client portal, run one scripted fictional client through every candidate, failures included. Write down how you get back before a single live client moves. Below is the worksheet blank, and filled in for a six-person studio deciding whether to move from Trello to ManyRequests.

It pairs with the software stack guide, which covers which tool should hold which record. If you are still shortlisting, start with the client portal comparison. This page is for when you have one or two names and a trial button in front of you.

Try the process fix first

Before you open a trial, name the handoff that is failing and who owns it. "Clients never know what is in progress" is a symptom. "Two clients ask for status in Slack every day, and whoever sees it first answers" is a handoff you can test a fix against.

Then try to fix it with what you already pay for. For a Trello studio that means one board per client, shared with that client, with three lists: Ready, In progress, With you for review. Run it for two weeks and count the Slack status questions before and after. If they stop, you have saved yourself a migration. If one client uses the board and the other keeps asking in Slack, you have learned something no portal demo will show you. Some clients will not log in to anything.

Write down the capability that is still missing after the process fix. That sentence is what every candidate gets judged against. If you cannot write it, keep Trello.

Script the trial before the clock starts

ManyRequests gives you a 14-day trial with no card required (ManyRequests pricing). Fourteen days goes quickly if day one disappears into settings. Write the scenario first, then sign up.

Signing up and building a request form is not the test. The test is one fictional client taken through the awkward parts of a normal month:

• An incomplete brief that should be stopped at intake, then a complete one that should land in the ready queue.
• A priority change before work starts, and a second request arriving while one is active.
• A blocked request, a restart, and two people at the client leaving opposite feedback on the same Figma frame.
• A revised version that needs an explicit approval, not a thumbs-up emoji.
• A paused subscription or failed payment, and what the client can still see and submit afterwards.
• A second client user who must not see the first client's files, and an export you actually open.

Use invented names and a fictional company. Do not connect your live Stripe account or upload real client files to a trial. Record what you saw, including every manual step, and keep it apart from what the vendor's documentation says. A candidate that only passes the happy path has not passed.

The filled-in example

Filled-in example (illustrative): a six-person studio deciding whether to move from Trello to ManyRequests. The studio, clients and outcomes are invented to show how a completed worksheet reads. They are not results from using ManyRequests. Only the prices come from the vendors.

Do the cost line properly, because seats add up. ManyRequests Pro is $99 a month billed monthly or $79 a month billed annually, with one seat included. Extra Pro seats are $30 a month, or $25 on annual billing. Six internal users therefore cost $99 plus five seats at $30, which is $249 a month. On annual billing that is $79 plus five at $25, or $204 a month. Trello Premium for the same six people is $75 a month billed monthly or $60 billed annually, at $12.50 and $10 per user (Trello pricing). All prices. The portal costs $144 to $174 a month more. For a studio whose clients pay £2,500 to £4,000 a month, the real question is whether it stops the status messages and keeps the client who ignored the Trello board.

DECISION CONTEXT
Decision owner / affected delivery owner: Dana, founder / Priya, senior designer who runs the queue
Current failed handoff and evidence: two clients ask for status in Slack every working day; counted over two weeks
Process-only repair attempted and result: a client-visible Trello board per client for two weeks; one of the two clients used it, the other kept asking in Slack
Capability that remains missing: one place per client for request, status and invoice, with several client users on one account
Required permissions / data restrictions: fictional data only; no live Stripe connection; no real client files uploaded
Candidate / account plan / evaluation date: ManyRequests Pro, 14-day trial, no card / six internal users = $249 a month billed monthly or $204 a month billed annually / September 2026
Evaluator / test environment limitations: Priya ran the trial; the client side was played by Dana from a second email address, not by a real client
Acceptance condition and unacceptable failure: accept if a client user can check status and submit without messaging us; reject if one client can see another client's files

REPEATABLE SCENARIO (record observed outcome, not a feature tick)
Fictional client / request reference: "Northgate Coffee", REQ-T01 to REQ-T04
Incomplete brief -> intake / blocker outcome: required fields stopped the empty form; a vague one-line brief still got through and Priya had to reply by hand
Complete brief -> ready queue outcome: arrived in the queue with the brief attached; nobody needed to post in Slack
Priority change before start outcome: Priya reordered the queue; Dana saw the new order as the client after a refresh
Start under active-request limit outcome: second request waited in the queue; the one-at-a-time rule was kept by Priya, as it is on Trello
Blocked request / restart outcome: marked blocked with a note asking for the logo file; restarted the next day with the reason still in the history
Conflicting feedback -> consolidated instruction outcome: two client users left opposite notes on the same Figma link; Priya wrote one consolidated instruction by hand
Revised version -> explicit approval outcome: v2 posted, client user approved it; the record shows who approved and when
Final files / history preservation outcome: final PNG and Figma link still on the request after it closed
Pause or failed payment -> service-state outcome: not tested; no live Stripe account connected to a trial. Question sent to the vendor
Guest access / account isolation outcome: a second fictional client could not see Northgate's requests or files; checked from both logins
Export relationships and missing fields: export opened in a spreadsheet and checked against the four test requests; approval history to confirm with the vendor
Manual steps and responsible roles: consolidating feedback (Priya); weekly invoice check against Stripe (Dana)
Evidence reference / observation limitations: screenshots in the Drive folder "Portal trial Sept 2026"; one tester, fictional data, 14 days
Documentation-only claims / source / unresolved questions: recurring payments and branded invoices (vendor pricing page); do client users need paid seats? Confirm before the pilot
[x] Same scenario used for each candidate (one candidate this round)
[x] No trial action charged or messaged a real client
[x] Failure cases included, not only the happy path
Evaluation decision: [ ] Keep current  [ ] Reject  [ ] Investigate  [x] Pilot
Reason / decision owner: the client who ignored the Trello board is the real test; pilot with two clients for one month / Dana

RECORD OWNERSHIP AND MIGRATION INVENTORY (pilot clients only)
Client identity source / destination / stable reference: Trello board -> ManyRequests client account; client codes C04 and C06 used in both
Request status source / destination / mapping: open Trello cards re-entered by hand; Ready -> queue, In progress -> in progress, With you -> in review
Approval history and version references: past approvals stay on the Trello cards; not re-entered
Files / asset permissions / access owner: Figma and Google Drive links copied onto each request; Dana opened every link from a client login, not a studio one
Subscription and invoice responsibilities: Stripe subscriptions not moved during the pilot; Dana reconciles each pilot invoice against Stripe weekly
Integrations / event owner / duplicate handling: nothing moved; Slack alerts stay on Trello until cutover
Excluded or unsupported records and reason: requests closed more than 90 days ago stay in the Trello archive
Export location / retention rule / access restriction: Trello board export (request history) in Drive "Trello archive 2026", founders only, kept two years
Warning written on the export folder: An exported list of links is not a usable archive if the linked assets become inaccessible.
[x] Export opened and checked, not merely created
[ ] Payment credential or mandate transfer confirmed with providers (not needed: Stripe stays put for the pilot)

PILOT AND CUTOVER
Pilot scope / client communication owner: two clients, one month / Dana
System of record during transition: Trello for all clients except the two pilots
Rollback trigger / decision owner: either pilot client asks for status in Slack more than twice in a week, or an invoice fails to reconcile / Dana
Manual fallback and reconciliation method: pilot boards stay in Trello, read-only, for the whole month
Post-move review date / unresolved issue owner: last Friday of the pilot month / Dana

Notice what the example does not do. It does not move every client, and it does not touch Stripe. The decision is a one-month pilot with a trigger that sends it back, which is a much smaller bet than a switch.

Plan the way back before you move

Most migrations go wrong at the part nobody wrote down: which tool is the source of truth on the Wednesday of week two. Pick one per client and put it on the worksheet. In the example, Trello stays the source for every client except the two pilots, so nobody on the team has to guess where to look.

Set the rollback trigger before the pilot starts, as a number with a name next to it. "If it is not working" is not a trigger. "Either pilot client asks for status in Slack more than twice in a week" is. Keep the old boards read-only for the whole pilot, so going back takes an afternoon rather than a rebuild.

Open every export you make. An exported list of links is not a usable archive if the linked assets become inaccessible. Check that Figma and Drive links open for someone outside the studio, and that access does not hang off a freelancer's account you are about to remove.

Do not treat a billing migration as an ordinary file copy. Card details and payment mandates are not something you carry across yourself. Any transfer goes through a process the providers support, confirmed with them before you plan around it. The simplest pilot leaves Stripe subscriptions where they are and reconciles by hand each week. The billing and retention guide covers matching what a client has paid for against the requests they have open while things change.

If the pilot passes, move the remaining clients in small groups, not all at once. If you are weighing a full agency platform rather than a portal, the agency platform comparison covers the extra records you would be moving, such as time tracking and capacity.

STUDIOSIFT | SOFTWARE EVALUATION AND MIGRATION WORKSHEET
Use fictional trial data. Keep credentials outside this document.
Complete evaluation before deciding whether to migrate.

DECISION CONTEXT
Decision owner / affected delivery owner: ____
Current failed handoff and evidence: ____
Process-only repair attempted and result: ____
Capability that remains missing: ____
Required permissions / data restrictions: ____
Candidate / account plan / evaluation date: ____
Evaluator / test environment limitations: ____
Acceptance condition and unacceptable failure: ____

REPEATABLE SCENARIO (record observed outcome, not a feature tick)
Fictional client / request reference: ____
Incomplete brief -> intake / blocker outcome: ____
Complete brief -> ready queue outcome: ____
Priority change before start outcome: ____
Start under active-request limit outcome: ____
Blocked request / restart outcome: ____
Conflicting feedback -> consolidated instruction outcome: ____
Revised version -> explicit approval outcome: ____
Final files / history preservation outcome: ____
Pause or failed payment -> service-state outcome: ____
Guest access / account isolation outcome: ____
Export relationships and missing fields: ____
Manual steps and responsible roles: ____
Evidence reference / observation limitations: ____
Documentation-only claims / source / unresolved questions: ____
[ ] Same scenario used for each candidate
[ ] No trial action charged or messaged a real client
[ ] Failure cases included, not only the happy path
Evaluation decision: [ ] Keep current  [ ] Reject  [ ] Investigate  [ ] Pilot
Reason / decision owner: ____

RECORD OWNERSHIP AND MIGRATION INVENTORY
Client identity source / destination / stable reference: ____
Request status source / destination / mapping: ____
Approval history and version references: ____
Files / asset permissions / access owner: ____
Subscription and invoice responsibilities: ____
Integrations / event owner / duplicate handling: ____
Excluded or unsupported records and reason: ____
Export location / retention rule / access restriction: ____
[ ] Export opened and checked, not merely created
[ ] Relationships and identifiers reconciled
[ ] Payment credential or mandate transfer confirmed with providers

PILOT AND CUTOVER (only after approval)
Pilot scope / client communication owner: ____
Acceptance evidence required: ____
Write freeze / handover point / exception handling: ____
System of record during transition: ____
Rollback trigger / decision owner: ____
Manual fallback and reconciliation method: ____
Duplicate-event prevention / recovery check: ____
[ ] Client and internal permissions checked in the new system
[ ] Active work, files and billing states reconciled
[ ] Team and affected clients know the new operating path
Cutover approved by / recorded date: ____
Old access revocation owner / retained-history location: ____
Post-move review date / unresolved issue owner: ____