Migrate from Looker to Lightdash

Migrate from Looker to Lightdash: what the move involves

Migrating from Looker to Lightdash means moving LookML logic into dbt YAML metrics and dbt models, then rebuilding dashboards and checking them side by side against Looker before the renewal date. Lightdash reads its semantic layer from a dbt project, so the work is less about copying charts and more about deciding where each view, dimension, measure, explore and join belongs in the warehouse and in version control. Data engineers usually own the dbt models and joins, analytics engineers own the metric definitions, and a platform owner sets up hosting, the PostgreSQL metadata database, object storage and upgrades. The effort scales with the size of the LookML codebase and with how well the warehouse is already modeled, so a team with clean star-schema tables will move faster than one whose explores depend on heavy LookML logic.

The main risk sits in persistent derived tables and access rules, not in charts. Each PDT that Looker builds inside the database has to be recreated as a warehouse model or view that someone schedules and monitors, and its refresh behavior needs to match what dashboards expect. Lightdash metrics are defined under meta: metrics: in dbt YAML and stored in the customer's Git repository, which keeps definitions reviewable, but the Looker user attributes, row-level filters and content permissions must be mapped by hand to whatever access model you run. Confirm which of those controls your chosen edition provides, because the supplied pricing information places SSO with SAML and SCIM 2.0, custom roles and service accounts on the Enterprise plan, and the Enterprise on-premises setup depends on a license key set through LIGHTDASH_LICENSE_KEY.

Before you start, export the LookML project from its Git repository, inventory every explore and PDT, and run both systems on the same questions for a fixed set of dashboards until the numbers agree. Ask Lightdash for the current version and release cadence you should plan around, since the project publishes new releases frequently and self-hosted instances need a regular upgrade routine. Ask your Google Cloud account team which Looker contract terms and renewal dates apply, because that date sets how long the parallel run can last. Keep the reconciliation log as evidence for the business owners who sign off on each migrated dashboard.

Which Looker capabilities map to Lightdash and which need rework

This table maps each major Looker capability to its Lightdash equivalent and marks it as clean, needs rework or gap. Read it as a planning checklist: anything marked needs rework has a model or license decision attached, and anything marked gap needs a workaround or a confirmed alternative before the Looker renewal date. Confirm feature details against the current Lightdash documentation for your version.

Looker capability	Lightdash equivalent	Status and what to do
Views, dimensions and measures	Columns and metrics in dbt YAML under meta: metrics:, read from a dbt project (v1.4.0 and above)	Needs rework. Rewrite each LookML measure as a dbt metric definition and confirm each aggregate type maps.
Explores and joins	Models built as dbt models with joins in SQL, exposed to Lightdash as explores	Needs rework. Rebuild join logic in dbt models and validate row counts against Looker results.
Persistent derived tables (PDTs)	Tables or incremental models created in the warehouse by dbt	Needs rework. Recreate PDT logic as dbt models and confirm refresh schedules move to your orchestrator.
Dashboards and Looks	Lightdash dashboards and saved charts built on dbt-defined metrics	Needs rework. Rebuild each dashboard and compare outputs side by side before cutover. Confirm the visualization types you need.
Git-based development	Metric definitions stay in your dbt Git repository alongside models	Clean. The LookML repository becomes the dbt repository, and review and branching follow your existing Git workflow.
User permissions and roles	Project and space access, with custom roles on Enterprise	Needs rework. Map Looker roles to Lightdash roles. Custom roles are a paid Enterprise feature, so confirm the license level you need.
SSO and SCIM provisioning	SSO with SAML and SCIM 2.0 on Enterprise	Gap on Open Source. Requires a paid Enterprise license key set through LIGHTDASH_LICENSE_KEY. Confirm IdP compatibility.
Scheduled deliveries and alerts	Not covered by the researched facts for this page	Gap to confirm. Ask Lightdash whether scheduled deliveries and alerts match your Looker usage before planning.

What to export from Looker and what to rebuild in Lightdash

Migrating from Looker is mostly an inventory exercise: what leaves Looker as files, what must be recreated in dbt and the warehouse, and what your self-hosted Lightdash instance needs to run. The cards below follow that order, so each export has a matching rebuild task and a check before the Looker renewal date.

LookML models from Git

Each LookML project corresponds to a Git repository, and Looker connects to remote providers such as GitHub, GitLab or Bitbucket over HTTPS or SSH. Your model and view files are the authoritative source for measures, dimensions, explores and joins, so clone that repository first and confirm you have every branch in use, not only the production branch. Check whether any logic lives only in the Looker UI, which will not appear in the repository.

Dashboards and query results

Looks, Explores and dashboards can be exported as query results and dashboard downloads, which give you the numbers to compare against later. These exports capture output, not logic, so they serve as acceptance baselines rather than migration sources. Save a dated set for each dashboard that finance, operations or regulators rely on, and record the filters used so the comparison is repeatable.

Permission-based row limits

Looker applies row limits and permissions to what a given user can extract, so an export run under an administrator account may return more rows than an analyst account would. Extract under an account with the access your data owners approve, and note which datasets were truncated. Decide in advance how row-level security rules in Looker map to Lightdash, since those controls must be rebuilt, not exported.

dbt models and metric YAML

Lightdash reads its semantic layer from a dbt project supporting v1.4.0 and above, and defines metrics under meta: metrics: in dbt YAML. Convert each LookML measure into a metric, then decide which explores become dbt models with joins expressed in the warehouse. Store the resulting YAML in the same Git repository as your models so definitions stay under version control, not inside the BI tool's database.

Persistent derived tables in the warehouse

Persistent derived tables (PDTs) are built and refreshed by Looker, so nothing in the warehouse replaces them automatically once Looker is off. Rebuild each one as a dbt model or a scheduled warehouse table with its own refresh and ownership. Confirm the refresh cadence each dashboard depends on, and check that the new job runs in your orchestrator before Looker's schedules are disabled.

Object storage, PostgreSQL and identity

A self-hosted Lightdash instance needs a PostgreSQL metadata database and S3-compatible object storage, deployed through Docker Compose or the official Helm chart. Enterprise features also need a license key set through LIGHTDASH_LICENSE_KEY and a PostgreSQL database with the pgvector extension. Plan identity integration early: SSO with SAML and SCIM 2.0 is listed on the Enterprise plan, so confirm your identity provider and group mapping before user onboarding.

The migration sequence from inventory to Looker decommission

This sequence moves a LookML semantic layer into dbt-based Lightdash in stages, so each phase produces an inventory, a tested model or a comparison that the next phase depends on. It ends with Looker decommissioned only after dashboards match and the renewal decision is made.

Inventory LookML views, explores, PDTs and dashboards
Your BI or analytics engineering lead lists every LookML view, explore, persistent derived table (PDT), dashboard and scheduled delivery, and tags each with its owner, audience and the warehouse tables it reads. Use the Looker admin pages and the project files together, because dashboards and schedules are not stored in Git. The output is a single inventory sheet with a keep, rewrite or retire decision for each item, reviewed by the business owners who rely on those dashboards.
Clone the LookML repository and freeze a baseline
Each LookML project is backed by a Git repository, so the platform team clones it from the remote provider (GitHub, GitLab or Bitbucket) into a migration repository that the Looker team does not write to during the project. Record the commit hash that the baseline dashboards were checked against. Done means the clone builds locally, the commit is tagged and the team agrees which commit the parallel run will compare against.
Convert measures into dbt YAML metrics and rebuild joins
Analytics engineers translate LookML measures into Lightdash metrics defined under meta: metrics: in dbt YAML, and rebuild explores and joins as dbt models with tests on keys and filters. Measures that depend on Looker-specific templating or liquid logic usually need to be rewritten in SQL in the warehouse or in a dbt model. Done means each converted metric returns the same value as its LookML counterpart on a agreed sample of filters, and the dbt project compiles and runs its tests.
Recreate PDTs as warehouse models
Each persistent derived table is rebuilt as a dbt model or a scheduled warehouse object, with its refresh schedule and incremental logic reproduced in the transformation tool rather than in a BI cache. Data engineering confirms the target schema, permissions and run order that Looker previously handled. Done means the rebuilt tables match the PDT row counts and key totals for the baseline period, and the refresh runs on the orchestrator you chose.
Stand up self-hosted Lightdash
The platform team deploys Lightdash in your own cloud account or data center using the official Helm chart for Kubernetes or the minimal Docker Compose setup, with a PostgreSQL metadata database and S3-compatible object storage. Confirm the release to deploy at build time against the project's GitHub releases page, since new versions ship frequently. Done means the instance starts, connects to the warehouse, reads the dbt project and passes a health check, and the team has written down its upgrade routine.
Pilot one business domain
Choose one domain with a bounded set of dashboards and a willing audience, then load its dbt metrics and explores into Lightdash and rebuild only those dashboards. Confirm which features the pilot needs, such as SSO, custom roles or SCIM, and check them against the license terms in the Lightdash pricing and enterprise documentation before depending on them. Done means the pilot users complete their usual tasks, and the open issues list is short enough for the team to act on.
Run dashboards in parallel and compare outputs
For the agreed period, Looker and Lightdash both serve the migrated dashboards while analysts compare totals, filter behavior, scheduled deliveries and row counts for the same date ranges. Record each variance with its cause, whether a rounding rule, a join change or a timezone difference. Done means every variance is either fixed or accepted in writing by the metric owner, and the comparison log is kept with the migration repository.
Cut over by audience and decommission Looker
Move users to Lightdash one audience at a time, keeping Looker read-only for each group until its dashboards are signed off, then retire scheduled deliveries and data access in Looker. Decommissioning happens only after the renewal decision is made, so confirm the contract end date, data export obligations and retention requirements with procurement and legal before turning off access. Done means Looker is no longer used for production reporting, exports are archived, and the Git repository stays as the record of the semantic layer.

What drives migration cost and duration

This table breaks the migration from Looker to Lightdash into the cost components you will pay for and the drivers that move each one up or down. Use it to build the internal effort estimate and to decide what to request in a written quote, since no price or duration is stated here. The main takeaway is that LookML volume, PDT complexity and dbt maturity usually matter more than the Lightdash license choice.

Driver or component	Why it moves cost or effort	How to keep it down
Number of LookML views and explores	Each view and explore must be rebuilt as dbt models, joins and metric YAML, so effort grows with object count and join depth.	Inventory views and explores first, retire unused ones, and consolidate near-duplicate views before conversion.
Persistent derived tables (PDTs)	PDTs must be recreated as warehouse models with their own refresh logic, scheduling and testing, which is often the hardest part to rebuild.	Map each PDT to a dbt model, rank by business use, and move only the logic that dashboards still need.
Dashboard count and complexity	Every dashboard needs side-by-side validation of tiles, filters and numbers, so the validation workload scales with dashboards and their dependencies.	Prioritize the dashboards executives and finance use, and archive low-traffic content with the business owner's sign-off.
Identity and access setup	Looker permissions, groups and row-level access must map to Lightdash roles and warehouse-side controls, and sign-in configuration needs IT time.	Document current Looker groups and access rules early, and confirm which SSO and role features your Lightdash edition provides.
Enterprise license needs	Features such as SSO with SAML, SCIM 2.0, custom roles and on-premises support sit in paid plans, which changes the license line in the quote.	List the required features before requesting pricing, and compare them with the open source edition's scope.
dbt maturity	Teams with tested, documented dbt projects reuse existing models, while teams without dbt must first build the modeling layer Lightdash reads from.	Assess current dbt coverage, tests and documentation, and fix gaps in the warehouse layer before conversion starts.
Infrastructure and warehouse query costs	Lightdash needs a PostgreSQL metadata database and S3-compatible storage, and parallel running doubles query load on the warehouse during validation.	Size the environments with your platform team, schedule validation queries, and ask the warehouse team for an estimate of parallel-run usage.
Internal staff time and ongoing upgrades	Analysts, data engineers and admins carry most effort, and Lightdash releases frequently, so a recurring upgrade routine is needed after go-live.	Name owners for dbt, Lightdash operations and business validation, and budget regular upgrade windows in the plan.

What usually goes wrong and how to prevent it

Most Looker to Lightdash migrations fail on definitions, schedules and assumptions rather than on the tool itself. The cards below cover the points where a parallel run can quietly diverge from production, and each one names the check that catches it before the Looker renewal decision.

Metric drift during parallel run

Once LookML measures are rewritten as dbt YAML metrics under meta: metrics:, two definitions of revenue or active users can exist at the same time. Filters, null handling and time grains often differ subtly between the two. Keep a written list of every measure that is being moved, compare Looker and Lightdash results for the same period and filters, and record each difference with an owner before any dashboard is switched over. Freeze LookML changes for the migrated measures during the comparison window.

PDT logic lost or rescheduled

Persistent derived tables in Looker are built and refreshed by Looker itself. In Lightdash they have no equivalent, so the SQL must be recreated as models in the warehouse with their own refresh schedule. A PDT that ran hourly in Looker may end up running nightly, or not at all, and dashboards then show stale numbers without an error. Inventory every PDT, record its trigger and dependencies, and confirm the replacement job runs on the same cadence with a freshness test on its output.

Access rules that do not match

Looker access depends on user attributes, model-level permissions and row-level filters defined in LookML. Lightdash controls access through its own roles and project permissions, and the equivalent row-level behavior has to be designed in the dbt models or the warehouse. Test with real accounts from each group: confirm that a regional manager sees only their region, that restricted columns stay hidden in exports, and that embedded or scheduled content inherits the same limits.

Assuming enterprise features are free

The open-source edition covers core BI features, but SSO with SAML, SCIM 2.0, custom roles, service accounts and on-premises deployment are listed under the Enterprise plan. Enterprise features also need a license key set through LIGHTDASH_LICENSE_KEY and a PostgreSQL database with the pgvector extension. Build a feature list from current Looker usage, mark each item as open source, paid plan or unknown, and confirm the unknown items with Lightdash before committing to a deployment design.

Falling behind Lightdash releases

Lightdash ships new versions frequently. The project's GitHub releases list version 2.603.0, published October 17, 2026, and a self-hosted instance that stays on an older build will drift from the features and fixes the migration plan assumed. Pin the version used for the pilot, record it in the runbook, and set a recurring upgrade window that includes a staging test of the dbt project and dashboards before production is upgraded.

Renewal signed before validation

Looker contracts often renew on a fixed date, and a renewal signed while dashboards are still being compared removes the leverage needed to keep a parallel run going. Set the validation exit criteria in writing first: which dashboards, which metrics, which users and how many consecutive matching periods. Ask Google Cloud or your reseller for the renewal term options and any short-term extension before the notice window closes, and treat the decision date as the outcome of validation rather than the other way round.

How the move differs by starting point

A small LookML project with a handful of views, a few explores and little persistent logic is usually the fastest case to move. The main work is reading each view and explore, mapping its dimensions and measures to dbt YAML metrics, and confirming that the warehouse tables they point to already exist in a form dbt can model. Because there are few objects, one person can often walk the whole project and rebuild it in a single pass, with the side-by-side check of dashboards as the final gate.

Inventory first: List every view, explore, join and dashboard in the Git repository so the scope is written down before any conversion starts.
Direct mapping: Simple dimensions and sums usually translate one to one into metrics under meta: metrics: in dbt YAML.
Small validation set: Pick the dashboards that finance or operations actually use and compare their numbers against Looker for the same filters.
Light infrastructure: A Docker Compose trial with PostgreSQL and S3-compatible storage is often enough to prove the setup before a production build.
Renewal timing: Confirm the Looker renewal date early so a short parallel run fits before the contract ends.

Before you commit, check whether your Looker contract requires notice periods or allows a short extension, and confirm with your vendor what the export and access rights are after renewal.

A team that already runs dbt has the most reusable starting point, because Lightdash reads its semantic layer from a dbt project and supports dbt v1.4.0 and above. The work shifts from modeling to reconciling: deciding which LookML logic already exists as dbt models, which metrics are missing, and where the two definitions disagree. Existing dbt tests, documentation and exposures can carry over, so the effort is concentrated in the metric layer and in the explores that combine several models.

Compare definitions: Check each LookML measure against the matching dbt model to find duplicates and conflicts before writing new YAML.
Add metrics in dbt YAML: Put new metrics under meta: metrics: in the existing schema files so they stay in version control with the models.
Reuse tests: Keep dbt tests as the gate for metric changes, so a broken model fails in CI before it reaches a dashboard.
Check dbt version and target: Confirm the dbt Core or dbt Cloud setup and the version in use meet Lightdash's requirements.
Retire duplicates: Remove any Looker-only logic that a dbt model already covers once dashboards match.

Confirm with your data team which dbt version and deployment target are in production, since that determines the integration steps.

How to run Looker and Lightdash in parallel before cutover

Run both tools against the same warehouse tables and treat the comparison as the cutover gate. Start by ranking Looker dashboards by business impact: the board pack, the finance close report, the pricing view that drives weekly decisions, and anything an external customer or regulator sees. For each one, pick a fixed reporting period, then compare totals, row counts and filtered results from the Looker Explore and the Lightdash explore built on the dbt model. Use identical filters, time zones and fiscal calendars, because most early mismatches come from those settings rather than from the metric logic. Record every difference in a discrepancy log with a root cause such as a join fan-out, a null-handling default, a deduplication rule, or a metric that was rewritten in dbt YAML.

Set the cutover criteria in writing before the Looker renewal date, not after the first clean run. Decide which dashboards must match exactly, which may differ by a documented rounding rule, and who signs off each group. Remember that parallel running adds warehouse query load, since both tools now execute similar queries, and persistent derived tables you rebuild in the warehouse may be refreshed on their own schedule. Ask your warehouse team to estimate the extra compute for the validation window, and confirm the Looker renewal terms so the parallel period ends with time to spare. Keep the Looker instance readable until every signed-off dashboard has passed, and export the LookML repository from its Git remote as a fallback.

Questions teams ask before moving from Looker to Lightdash

How much effort and cost does a move from Looker to Lightdash take?

The effort depends mainly on how much LookML logic you have and how much of it you can map cleanly to dbt. The main cost components are the people who convert views, dimensions and measures into dbt YAML metrics, rebuild explores and joins as dbt models, and recreate persistent derived tables in the warehouse, plus the infrastructure to run Lightdash and its PostgreSQL metadata database and S3-compatible object storage. The Lightdash Open Source edition has no license fee for core BI features, while Enterprise features need a license key. One-time work is the conversion and validation. Recurring costs are hosting, upgrades, support and the dbt maintenance your team keeps doing. Ask any provider for a quote built from a written inventory of your views, explores, dashboards and derived tables, and ask which Lightdash features the quote assumes you need.

How long does a Looker to Lightdash migration take?

No duration is fixed in advance, and the answer depends on your inventory. Teams with a small number of models, few explores and a dbt project already in place usually have less to convert than teams with many persistent derived tables, heavy use of custom SQL in LookML or dashboards that depend on Looker-specific features. Before you plan a timeline, count your LookML views, explores, dashboards, scheduled deliveries and PDTs, and note which ones feed executive or regulatory reporting. Validation side by side with Looker before the renewal date usually sets the critical path, so work backward from your Looker contract end date. Ask for a timeline that is tied to that inventory and to a written scope.

What does the migration need from our internal staff?

The work needs people who know your LookML, your warehouse and your business definitions. Lightdash reads its semantic layer from a dbt project and supports dbt v1.4.0 and above, so someone on your team must be able to work in dbt and in your Git repository. Analysts who own dashboards must confirm which metrics are correct, because a converted metric that differs from the Looker version is the most common validation failure. Platform engineers need Docker or Kubernetes experience to run the Lightdash deployment, which the self-hosting guide describes as aimed at DevOps engineers familiar with those tools. Plan time for these owners to review results, not only to build them.

Can our team migrate from Looker to Lightdash without outside help?

Yes, a team with dbt experience, container operations skills and a clear inventory can do the migration in house, and many teams do. Outside help is most useful when the LookML is large, the derived tables are complex, or the team lacks capacity to run side-by-side validation before the renewal. An implementation partner can work under a fixed-scope agreement with written deliverables and timelines, and DeployOpen offers implementation, integration, hardening, backup, upgrades and documentation inside your own infrastructure. DeployOpen does not publish a price list, and a quote follows from the written scope. Ask any partner what they will deliver, who on your side signs off on each metric, and what happens after go-live.

Does open-source Lightdash cover the features we use, or do we need a license key?

The MIT-licensed core of Lightdash covers core BI features at no license fee, and the ee directory is under a separate license. Lightdash's pricing page lists AI agents and MCP, embedding, dedicated support and migration assistance on Cloud Pro, and SSO with SAML and SCIM 2.0, custom roles and on-premises deployment on Enterprise. Enterprise Edition features in self-hosted deployments need a license key set through the LIGHTDASH_LICENSE_KEY environment variable and a PostgreSQL database with the pgvector extension. The key unlocks features including AI agents, embedding, custom roles, service accounts and SCIM. List the Looker features you actually use, such as SSO, scheduled deliveries, embedding and row-level permissions, and check each against this list before you assume the open-source edition covers it.

What happens to our LookML and persistent derived table logic?

LookML views, dimensions and measures move to dbt YAML metrics under meta: metrics: in your dbt project, and explores and joins are rebuilt as dbt models. Persistent derived tables do not map one to one to a Lightdash feature, so they are typically recreated as models or tables in the warehouse and then referenced from dbt. Logic that Looker computes inside a PDT, such as complex aggregation or incremental builds, needs to be re-implemented and tested in your transformation layer. Metric definitions then live in version control beside the dbt models, not in the BI tool's database. Keep the original LookML repository intact until side-by-side validation confirms each dashboard produces the same results.

How do we keep dashboards accurate during validation against Looker?

Run the converted Lightdash metrics and the original Looker dashboards side by side on the same data, and compare results for each key figure before any user switches. Check filters, time zones, null handling, aggregation types such as count distinct and percentile, and any post-calculations like running totals or percent of total, because small differences often come from these details rather than from the data. Confirm that row-level access and sharing rules match what viewers had in Looker. Record each reconciled metric in your Git repository so the sign-off travels with the code. Schedule this work so it completes before your Looker renewal decision, not after.

When Looker can be decommissioned safely

Looker can be decommissioned when five things are true: every dashboard that matters has been validated against Lightdash by its owners, the LookML project and saved Looks are archived outside Looker, user access has been removed, every scheduled delivery has a working replacement, and the renewal decision has been made in writing. Treat these as gates in order. Ask the business owner of each dashboard for a signed-off comparison, not just a successful build, because a metric that renders is not the same as a metric that matches the number the team trusts. Keep the sign-off record in the migration repository so auditors and future analysts can see what was approved and when.

Before access is removed, export the artifacts you will need later. Clone the LookML repository from its Git remote so the full history is preserved, and export Looks and dashboard definitions as an archive. The Looker documentation on the Git connection covers how the project maps to a repository, which tells you what to clone. Then remove user accounts and groups in stages, starting with viewers and ending with administrators who hold the final export rights. Confirm that no scheduled deliveries, alerts or embedded pages still point at Looker, since those will fail silently once the instance is gone.

The renewal decision is the last gate. Confirm with Google the notice period, the termination terms, the data retention and deletion commitments for the Looker instance, and whether any fee applies if you stop before the term ends. Ask for these terms in writing, because they depend on your contract and edition, not on this guide. Once the contract terms are clear and the earlier gates are closed, schedule the non-renewal and keep a read-only copy of the export until your retention policy allows deletion.

How DeployOpen scopes and runs a Looker to Lightdash migration

DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Looker to Lightdash move, we start from a written, fixed scope that covers the LookML repository, the dbt project, the warehouse objects and the dashboards that must match before the Looker renewal date.

How we scope

We inventory the LookML project in its Git repository, including views, explores, models and the dashboards that depend on them.
We map each measure and dimension to a dbt YAML metric or a warehouse model, and record what cannot move cleanly.
The written scope lists deliverables, timelines and acceptance checks for dashboards, agreed with you before any work starts.

How we build

We set up the Lightdash deployment in your environment, with PostgreSQL and S3-compatible storage, using the Helm chart or Docker Compose.
We rebuild explores and joins as dbt models and recreate persistent derived tables in your warehouse as versioned code.
We test metric results against Looker output side by side, so differences are found and explained before any cutover.

How we hand over

We document the dbt project layout, metric definitions, deployment configuration and the reconciliation results for your team.
We agree which Lightdash features your team will use, and confirm with Lightdash whether any need an Enterprise license key.
We walk your engineers through the upgrade routine, since Lightdash ships new versions frequently and self-hosted instances must keep pace.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope migration closes.
Retainers can cover Lightdash version upgrades, dbt model changes and periodic dashboard reconciliation as your data evolves.
Confirm the support hours, response expectations and ownership of the Git repository and warehouse objects in the written scope.

Migrate from Looker to Lightdash