Migrating from OpenSearch Dashboards to a Desktop Client
I wrote this for engineers who use OpenSearch Dashboards primarily as a query console rather than as a visualization or observability platform. If your daily work is writing and iterating on search requests, switching to a desktop client changes how you work more than it changes what you can do. For the product details and download path, see the OpenSearch GUI client page.
When Dashboards becomes the bottleneck
OpenSearch Dashboards makes sense when you need dashboards, alerting, observability views, and security administration in one web app. It starts to feel heavy when the actual task is query development. You wait for the Dashboards service to boot—often 10 to 30 seconds in local or containerized setups—before Dev Tools is usable. Many teams keep a separate Dashboards container running alongside the cluster even though the cluster is the only thing they actively query. Then you work in a browser tab that can be interrupted by refreshes, crashes, cookie issues, or session resets, which kills whatever editing context you had open.
That friction is small once, but costly when it happens dozens of times per day. Browser-based state is a poor home for work-in-progress query files. If Dashboards is your scratchpad, your important queries live in a mix of browser history, copied snippets, and saved objects that are hard to diff or commit. There is no real offline mode: if the cluster is unavailable, Dashboards is mostly unavailable too. Add the RAM cost of another Node-based web app on top of the cluster, and you can see why many teams treat Dashboards as necessary infrastructure for a workflow that doesn't actually need a browser-first tool.
What a desktop client does differently
The main difference is that query work stops being tied to a browser session. Queries become local files or editor state instead of temporary browser artifacts. That makes it easier to preserve, review, and reuse queries. You can keep inline notes, organize queries in folders, and treat them more like code than snippets buried in Dev Tools history.
The connection model changes as well. Dashboards assumes a running web application that is always connected to a cluster. A desktop client treats the cluster connection as part of the workflow, not the whole workflow. The editor can start instantly. Local history persists when you are offline. Switching environments becomes a profile change rather than a separate browser login flow. That matters most for engineers who move between local containers, staging clusters, and managed environments in a single day.
What you give up
Moving query work into a desktop client does not replace OpenSearch Dashboards. Dashboards still matters for visualizations and stakeholder-facing dashboards. It's where teams manage alerting rules, inspect observability data such as traces, logs, and metrics, administer the security plugin, and use features like Anomaly Detection. If your team depends on those parts of the stack, a desktop client is not a substitute.
Be explicit about this trade-off. A lighter client reduces overhead for query development; it does not make Dashboards unnecessary across the board. For many teams the steady state is running both tools: a desktop client for daily request authoring and cluster-side query checks, and Dashboards for visualization, alerting, and operational workflows that belong in a web UI.
Migration workflow
Start by identifying the saved queries and repeated Dev Tools requests you actually use. In Dashboards that usually means opening Dev Tools and collecting the requests your team reruns during development, incident reviews, schema checks, or release validation. Export them out of the browser mindset and into files. If there isn't a formal export for every snippet, copy the saved queries from Dev Tools Console into versioned files so they stop living only inside browser history.
Next, install the desktop client and create a connection profile that points to the same cluster you use in Dashboards. If you have separate local, staging, and production endpoints, create named profiles for each immediately. The point is to make environment switching explicit and repeatable, not to connect once and forget it.
Then recreate the queries you use most often in the new editor. Normalize them into JSON5 so they are easier to maintain and annotate. A strict JSON request copied from Dashboards might look like this:
GET /orders/_search
{
"query": {
"bool": {
"filter": [
{
"range": {
"createdAt": {
"gte": "now-7d/d"
}
}
},
{
"term": {
"status": "paid"
}
}
]
}
},
"size": 100
}The same request in JSON5 can be kept closer to how engineers actually annotate working queries:
GET /orders/_search
{
// Paid orders from the last 7 days
query: {
bool: {
filter: [
{
range: {
createdAt: {
gte: 'now-7d/d'
}
}
},
{
term: {
status: 'paid'
}
}
]
}
},
size: 100
}After you have queries in the desktop client, run both tools side-by-side for one to two weeks. Keep Dashboards available for the workflows that belong there, especially visualizations and any shared operational views. Use the desktop client for day-to-day request authoring, rerunning saved queries, and switching between environments. That overlap is usually enough to confirm whether the lighter workflow matches how your team works.
AWS OpenSearch Service specifics
For AWS-managed clusters point the client to the service HTTPS endpoint, typically https://search-your-domain.region.es.amazonaws.com or the newer endpoint shape your account uses. Credential options are direct AWS access keys or an IAM profile already configured on your machine. The important thing is to target the same managed cluster endpoint you already use, not a separate compatibility layer.
Running both tools
This is not a binary migration where Dashboards disappears. In practice you split responsibilities by job. Use the desktop client for daily query development, saved request libraries, local editing, and quick environment switching. Keep OpenSearch Dashboards for stakeholder dashboards, alerting flows, observability views, and administration that belongs in a web app.
That separation usually reduces friction. Engineers stop using the full Dashboards stack as a generic text editor while the valuable parts of Dashboards remain in place. If your team treats search requests as assets worth reviewing and reusing, coexisting tools are often the cleanest path.