RealGreen Mobile Live shut down: what to check now

How we work: This guide uses current public documentation and does not claim hands-on testing unless stated. Some links may later become affiliate links, at no added cost to you. Rankings are independent of commissions.

RealGreen Mobile Live reached end of life on July 31, 2026. That date has passed. If technicians are still working around missing functions, the useful question is no longer how to schedule a cutover — it is which Mobile Live capabilities did not survive it, and what RealGreen has actually committed to in writing.

That is harder to answer than it should be, because RealGreen’s own pages contradict each other on the central point. Its product interview says feature parity was reached and was the precondition for retiring Mobile Live. Its support FAQ, still published three weeks after the shutdown, says the replacement does not have as many features. Details below.

This is desk research against RealGreen’s public product and support pages, not a hands-on product test. Originally published July 28, 2026 as a pre-deadline cutover plan; rechecked and reframed on August 23, 2026, after the deadline passed. The checklist deliberately asks each company to test its own Service Assistant 5 configuration, devices, permissions, and field records.

Did RealGreen Mobile reach feature parity?

RealGreen has published both answers, and both pages are live.

Two things are worth separating here. The parity claim appears in a marketing Q&A, where it is a statement about a programme reaching its goal. The counter-claim appears in the support documentation a technician is sent to when something is missing, which is where it matters operationally. A support page that still describes the replacement as less capable, three weeks after the thing it replaced was switched off, is either out of date or accurate — and neither reading is comfortable.

The same FAQ carries a clearer sign of staleness. It still explains how a technician who prefers the old app can “log out of the RealGreen Mobile app, and then log into the Mobile Live app,” including how to reinstall Mobile Live with a QR scan sheet. That is a documented fallback to software that reached end of life on July 31. It is not a trap so much as a signal: treat the support site’s Mobile Live content as unverified until RealGreen updates it.

RealGreen Mobile is also still changing after the cutoff. Version 2.17, released July 30 and described by RealGreen on August 11, added direct invoice printing and emailing, a manual Update Configurations action for settings and route lists, required vehicle and odometer prompts, and fixes for a memory leak, master-product calculations, call-log saving, and customer-search proximity. These are concrete improvements, but they do not resolve the parity contradiction. They make version and workflow-level retesting more important: record which app release produced each result instead of treating “RealGreen Mobile” as a fixed capability set.

One smaller inconsistency, for anyone checking device requirements against a fleet: the FAQ currently lists the minimum as “Android: 9 and higher, iOS: 9 and higher,” while RealGreen’s setup guide has specified a considerably newer iOS floor. Confirm the requirement against your actual devices rather than either page.

So do not guess which page is newer, or which configuration the word “parity” covers. Build a list of the Mobile Live actions the company actually used, then mark each one:

• pass: completed in RealGreen Mobile and confirmed in Service Assistant 5;
• office workaround: completed in Service Assistant 5 with a named owner;
• support gap: no safe current path, with a support case number and business impact; or
• not used: confirmed by the process owner, not assumed by the migration lead.

Which cutover method is safest?

For a company with more than one crew, a branch or crew wave is the safest available method because it limits the number of live records exposed to an unknown configuration problem.

RealGreen’s product owner recommends starting larger deployments with a small group of senior technicians who can become trainers. The National Association of Landscape Professionals also recommends trials, early stakeholder involvement, advance training, and contingency plans rather than a rushed rollout.

Whichever method is still possible, assign four named roles:

1. cutover owner: decides whether a wave proceeds or stops;
2. Service Assistant 5 administrator: changes licenses and Mobile Admin settings;
3. field lead: observes the technician workflow and records failures; and
4. reconciliation owner: compares mobile activity with office records, timesheets, invoices, and payments.

One person can hold several roles in a small company. The responsibility still needs to be explicit.

A three-day cutover sequence

This was written as a countdown to July 31 and still works as a compressed sequence for whoever is moving next: a branch that was left behind, a crew added after the deadline, or an acquired book of business still on an old configuration. Read T-0 as the first day the company stops depending on Mobile Live rather than as a calendar date. Combine days if needed, but do not skip the pass criteria.

T-3: inventory devices, licenses, settings, and workflows

Start in Service Assistant 5. RealGreen says the replacement app requires Service Assistant 5, and technicians need Mobile App access before they can log in. The setup guide places mobile licensing under Settings > Company Setup > Mobile Licensing, with licenses assigned by branch and employee.

Create one row per active technician:

RealGreen’s setup guide lists Android 9 and newer and iOS 15 and newer as supported operating systems. Record the actual version rather than writing “current.” A device that cannot install or log in to the app is a deployment blocker, not a training issue.

Next, capture Mobile Admin settings that control field behavior. The official setup guide documents configuration areas for:

• login and route listing;
• route modification and reassignment;
• geocoding;
• daily checklists;
• timeclock behavior;
• production requirements;
• condition categories;
• hidden pricing;
• accepted payment methods;
• customer fields and call-log outcomes; and
• estimate upsells.

Use screenshots or a written setting export approved by the company’s security policy. Do not copy passwords or customer data into the cutover document.

Finally, inventory every Mobile Live action used during a normal week. Include rare but costly cases such as a not-serviceable stop, a reassigned route, a credit-hold customer, an estimate, an invoice reversal, a payment, and work completed without signal.

T-2: run one end-to-end pilot route

Use controlled records or a carefully supervised live route. Do not create fake production charges or customer communications merely to exercise a button.

The field lead should observe this sequence:

1. Log in with the technician’s own assigned access.
2. Confirm the current day’s jobs appear in the same order as the route list saved in Service Assistant 5.
3. Filter by the route or crew if that control is enabled.
4. Clock in, add the intended crew members, select the vehicle, and record the odometer through the company’s normal process.
5. Open job notes, accept the job, and start either the complete job or the intended individual service.
6. Record the fields the company requires, such as products, conditions, weather, customer notes, and before-and-after documents.
7. Complete the service, or mark a controlled case not serviceable.
8. Review the Daily Overview, then clock out.
9. Have the office confirm route status, production details, documents, timesheet entries, and crew assignments in Service Assistant 5.

This sequence follows RealGreen’s current technician tutorials, but it is not a claim that the workflow passed for any particular company.

Pay special attention to Quick Production. RealGreen’s FAQ says enabling it limits users to starting and completing jobs, without entering product, condition, weather, or customer-note details. If those details support application records, customer communication, job costing, or quality control, Quick Production can change the process materially. Test with the same setting the company plans to deploy.

T-1: move the remaining users and reconcile exceptions

Assign licenses and install the replacement app for the remaining approved wave. Give technicians a one-page task guide built from the company’s tested sequence, not a tour of every menu.

Run a reconciliation at midday and after the last route:

• all expected jobs are visible to the intended route or crew;
• every completed or not-serviceable service has the expected office status;
• start and stop times agree with the field record;
• crew members appear on the right timesheets;
• required products, conditions, notes, and documents are present;
• estimates and invoice actions have the intended status;
• payments, if used in the field, have the correct amount, method, customer, and employee assignment; and
• no controlled test record remains mixed with production reporting.

Open a support case for any unresolved gap, and do it now rather than after the next failed route. Include the app version, device and OS, branch, affected setting, exact steps, expected result, actual result, and business impact. Remove customer details unless support specifically requires them through an approved channel.

T-0: stop relying on Mobile Live

On or before the day the company stops depending on Mobile Live, communicate one internal source of truth:

• which app technicians must use;
• who can change Mobile Admin settings;
• where a technician reports a missing route or failed sync;
• which tasks have a Service Assistant 5 workaround; and
• who has authority to pause field changes while records are reconciled.

RealGreen’s FAQ describes Mobile Live and RealGreen Mobile as independent apps against the same database, installable together but not to be used at the same time, with the documented fallback being to log out of one and into the other. As above, that text has outlived the app it refers to; read it as history.

The questions it leaves open are worth putting to RealGreen support in writing: what “shut down” means for login, for records still held locally on a device that never synced, and for reinstallation. The public shutdown notice answers none of them, and a device sitting in a truck since July may still be holding work.

How should routes and schedule changes be tested?

RealGreen’s usage guide says the job list follows the route order saved in Service Assistant 5. Depending on permissions, a mobile user can filter by route or crew and may be able to reschedule or reassign a job or service before starting it.

Test one route with the cases the company uses:

• a normal production stop;
• several services on one job;
• a promised or confirmed visit;
• a job reassigned to another technician or route;
• a service moved to another date or time;
• a not-serviceable stop; and
• a posted job that should no longer be editable.

The pass condition is not simply “the route loaded.” The office must see the intended order, assignee, scheduled date, status, and downstream customer or billing effect.

This migration does not replace route-quality testing. If the company is also changing route rules, use the recurring landscaping route-planning checklist to test fixed times, crew constraints, rain-day changes, and service duration separately.

How should crew clocks and production records be verified?

RealGreen’s technician tutorial says the user can open Timesheets, add crew members, clock in, update a vehicle odometer, perform work, review the Daily Overview, and clock out. The setup guide also documents timeclock and production requirement settings.

Use one comparison sheet per pilot day:

Do not use a successful login as evidence that payroll-related records are correct. Compare the actual employee, crew, date, and time fields that payroll or job costing consumes.

How should estimates, invoices, and payments be checked?

RealGreen’s February update says RealGreen Mobile can surface scheduled estimates in the route list, complete estimates, add notes, view invoices from the job card, and manually undo previously invoiced services. The setup guide also documents settings for accepted payment methods and estimate upsells.

Run only the financial paths the company actually uses:

1. Open a scheduled estimate from the route list and verify the customer, property, source, size, route, services, and notes.
2. Complete the estimate through the approved process and confirm its status in Service Assistant 5.
3. Open an existing invoice from the job card and confirm it is the intended customer and work.
4. Test an undo-invoice action only with an approved controlled record, then confirm the service status returns to the expected office state.
5. If technicians take payments, confirm the allowed methods, amount, assignment, receipt or invoice display, and office posting.

This is also the right time to verify estimating requirements rather than assuming the new interface enforces them. The landscaping estimating software decision matrix lists the labor, material, production-rate, approval, and estimated-versus-actual checks that belong in a broader estimate workflow.

How should offline sync be tested?

RealGreen says an internet connection is needed for real-time synchronization. When no connection is available, changes are stored in RealGreen Mobile and sync after the connection returns.

Verify that claim against the company’s devices and records:

1. Use a controlled job that is already visible on the device.
2. Record the app version, device, OS, job status, and last known office state.
3. Disable connectivity through the device’s normal settings.
4. Perform the approved offline actions, including the exact notes or documents needed to identify the test.
5. Confirm the app shows a clear local or pending state. Record what the user can actually see.
6. Restore connectivity and wait through the app’s documented normal process.
7. Confirm each field in Service Assistant 5, then confirm the app no longer presents the work as pending.
8. Test one conflicting office change only with vendor guidance or a non-production record. Do not discover conflict behavior on a live invoice.

Do not claim “offline passed” because a screen remained open. The pass condition is that the intended change reaches the correct office record once, without a lost field, duplicate, or silent overwrite.

What is a workable rollback plan?

Rollback means keeping field operations safe while a failed wave is diagnosed. It does not mean falling back to Mobile Live.

That distinction now matters more than it did, because RealGreen’s FAQ still describes the old fallback as though it were available: a technician who kept Mobile Live installed can log out of RealGreen Mobile and log into Mobile Live, reinstalling from a QR scan sheet if necessary. Mobile Live reached end of life on July 31, 2026, so plan as if that route is closed and confirm with RealGreen support before anyone spends a service day finding out. A rollback plan built on a retired app is not a rollback plan.

For each cutover wave, write down:

• the stop condition, such as missing routes, incorrect crew clocks, duplicate records, or failed synchronization;
• who tells technicians to stop entering changes;
• which app or Service Assistant 5 process is authorized next;
• how the office identifies the last trusted record;
• how field notes are captured securely during the pause;
• who reconciles records before work resumes; and
• when the rollback route expires.

NALP’s implementation guidance is direct: assume new technology can fail, prepare a contingency, and protect customers from rollout problems. After July 31, the practical contingency may be an office-led Service Assistant 5 process plus a controlled temporary field procedure, not the retired app. Get that answer from RealGreen before it is needed.

What should be kept after the cutover?

Keep a short evidence pack that avoids sensitive customer data:

• the confirmed shutdown notice and date checked;
• technician and device readiness list;
• Mobile Admin setting record;
• workflow matrix with pass, workaround, support gap, or not-used status;
• pilot date, app versions, and participants;
• reconciliation sign-off for routes, time, production, estimates, invoices, payments, and sync;
• support case numbers and owners; and
• the post-shutdown contingency.

The goal is not to produce paperwork. It is to prevent an undocumented setting or failed sync from becoming a route, payroll, billing, or customer problem.

For a broader view of how customer, route, estimate, and invoice records fit together, start with the landscaping CRM comparison. For the source and correction standards used in this desk research, see the editorial policy.